MySQL занял первое место (http://www.mysql.com/news-and-events/press-release/release_2...) в соревновании организованном журналом "C’T magazine".
В качестве теста оценивалась скорость обслуживания заявок в виртуальном интернет-магазине (http://firebird.sourceforge.net/connect/ct-dbContest.html).
Общие результаты (http://www.mysqlperformanceblog.com/2006/08/29/mysql-wins-ct.../):
- MySQL5/PHP: 3664 заказов в минуту (opm);
- DB2/Java : 1537 opm;
- Oracle / Java: 1412 opm;
- PostgreSQL / PHP: 120 opm (не опечатка);
Следует заметить, что специалистам по тюнингу MySQL удалось (http://www.mysqlperformanceblog.com/2006/08/29/mysql-wins-ct.../) на том же оборудовании достичь значения в 7000 opm для MySQL5/PHP. Скорее всего низкий результат для PostgreSQL обусловлен использованием конфигурации по умолчанию, не предназначенной для нагруженных серверов.
URL: http://www.mysql.com/news-and-events/press-release/release_2...
Новость: http://www.opennet.me/opennews/art.shtml?num=8249
замечу, что в php упор сделан на mysql, и его либа теперь вылизана и отточена, в отличие от либы для постгре. это всего лишь значит что надо еше дорабатывать
И placeholder'ы есть?
ты хоть понял че сказал?
как можно вылизать простой вызов API Postgres или MySQL.
просто линкуется либа и просто вызывается функция. как в обычном приложении. что можно оптимизировать? если и возможен где-то момет оптимизации, так это при fetch(PGSQL_ASSOC), да и то несущественно в глобальном смысле
А что вы скажете про Java? :)
Хотя по-моему тестировать надо одинаковом окружении.А то Java сама по себе тот еще тормоз - может, не DB виновата то была?
Ктото слабо ориентируется в вопросе. Ява конечно может и тормознее C как прикладной язык -
такова плата за кроссплатформенность. Но не сильно. А вот супротив PHP/Perl и пр. Java
просто реактивный самолет против кукуризника. Вот только почему сравнивали PHP+MySQL с Java+Oracle и Java+DB2 мне не ясно. Гонки между белазами и феррари никому веть в голову не приходит устраивать - задачи у этих машин разные и возможности.
А как тогда кукурузник натянул реактивный самолет?Получается, что Оракл и DB2 ваще настолько лохи что даже Java их не спасла???
Мерили всетаки производительность работы с базой данных а не просто производительность.
И вообще-то, да, Oracle и DB2 медленнее, чего собственно никто и не скрывает. Еще раз повторяю это "тяжелые" базы данных, по своим возможностям превосходящие mysql на порядок. Они принципиально для других вещей сделаны. Сравнивать их просто некорректно. Тем более некорректно сравнивать связку MySQL/PHP со связкой Java/Oracle. Кто-нибуть видел чтоб на java+oracle Вася Пупкин домашнюю страничку рисовал ?
Этот конкурс не имеет ровным счетом никакого отношения к сравнению производительности СУБД (это сравнение разных решений написаных разными ~ случайными людьми, из которых серьезная только команда разработчиков MYSQL AB)Рекомендую поглядеть:
http://groups.google.com/group/pgsql.general/browse_frm/thre...
Рызултаты того, что вы называете "сравнению производительности СУБД" - в стюдию!!!Неужели тяжело ссылку сюда кинуть???
А почему? Почему так тяжело?
Ха-ха ... значит постгрес в двадчать раз медленее? Ха-ха ... это _как_ же его надо бояться чтоб такое писать! А боятся правильно - постгре скоро всех зарулит! No doubt.
>Ха-ха ... значит постгрес в двадчать раз медленее? Ха-ха ... это _как_
>же его надо бояться чтоб такое писать! А боятся правильно -
>постгре скоро всех зарулит! No doubt.
Не надо бояться Постгреса, не надо.Надо ссылочку сюда бросить. Если есть.
Я уверен, что это не постгрес медленный, а у кого-то руки не тем концом и не туда приделаны.
>Я уверен, что это не постгрес медленный, а у кого-то руки не
>тем концом и не туда приделаны.Вы просто не работали с БЫСТРОЙ базой.
И плохо понимаете, насколько My5 уделывает Постгреса и Оракла.
А где, кроме примитивных баз для web можно его использовать?
>А где, кроме примитивных баз для web можно его использовать?его отлично можно использовать, например, как высокозагруженный источник данных для Оракл
где Оракл сосет из Мускуля результаты работы клиентов и прокручивает через частично реализованную в себе бизнес-логику, поверх которой например работает биллинг, написанный на чем угодно. отличная схема распределения нагрузки для больших систем
Нужно сказать, что неспроста Оракал вдруг заделался Експрессом и вообще в 100 раз снизил цены лицензий. Корячится ему кабзда. Ровно такая, какая пришла Нетвари. Чмякс - и мокрое место.
>его отлично можно использовать, например, как высокозагруженный источник данных для Оракл
>где Оракл сосет из Мускуля результаты работы клиентов и прокручивает через частично
>реализованную в себе бизнес-логику, поверх которой например работает биллинг, написанный на
>чем угодно. отличная схема распределения нагрузки для больших систем
Чем ? У вас может стать узким местом мост между mysql и Oracle. MySQL на данный момент не годится для серьезных проектов. Извините, но СУБД у которой только в 5 версии появились хранимые процедуры это мягко говоря та еще фигня. Насчет java+oracle все зависит от задачи и того как производилась оптимизация запросов и собственно как писали на java. Если же писать как на php то собственно ничего удивительного.PS Кстати ознакомьтесь:
http://caucho.com/resin-3.1/quercus/Рекомедую обратить внимание на:
Performance: Quercus outperforms a straight mod_php implementation by about 4x (for Mediawiki and Drupal). Quercus roughly matches PHP performance with accelerators like APC.
>Чем ? У вас может стать узким местом мост между mysql и
>Oracle. MySQL на данный момент не годится для серьезных проектов. Извините,
>но СУБД у которой только в 5 версии появились хранимые процедуры
>это мягко говоря та еще фигня.мне не нужны хранимые процедуры, мне не нужны сложные GROUP BY и пр. мне нужны простые быстрые селекты, апдейты и инсерты. например, несколько моих мускулей обслуживают каждый около тысячи порстых запросов в секунду. часть результатов периодически переливается в Оракл, где есть все и неспешно пропускается через хранимые процедуры и прочую лабуду.
позвольте уж мне из _собственного_ _реального_ опыта создания и поддержки таких систем судить о том, что я утверждаю
>мне не нужны хранимые процедуры, мне не нужны сложные GROUP BY и
>пр. мне нужны простые быстрые селекты, апдейты и инсерты.
Как только они станут нужны вы выкините MySQL.>например, несколько моих мускулей обслуживают каждый около тысячи порстых запросов в секунду.
У меня один столько лопатит. Но только с InnoDB и после тюнинга. Т.к. у базы в 100гиг в MyISAM слетают индексы. А InnoDB этим не страдает. Но и его надо тюнить надо иначе тормозит.>часть результатов периодически переливается в Оракл, где есть все и неспешно пропускается
>через хранимые процедуры и прочую лабуду.
А почему сразу не обрабатывать и передавать в Оракл?>позвольте уж мне из _собственного_ _реального_ опыта создания и поддержки таких систем
>судить о том, что я утверждаю
Позвольте мне так же судить из собственного реального опыта. Для очень простых вещей укладывающихся в SQL89 можно использовать MySQL. Для более сложных нет.
> Как только они станут нужны вы выкините MySQL.
в той части, в которой работает мускуль, хранимые процедуры и пр. не понадобятся никогда :) это достаточно разумно спроектированная система.> А почему сразу не обрабатывать и передавать в Оракл?
знаете, это как с протоколами OSI> Позвольте мне так же судить из собственного реального опыта. Для очень простых вещей
> укладывающихся в SQL89 можно использовать MySQL. Для более сложных нет.
а я считаю что при проектировании надо задумываться о будущем, стремиться сделать максимально просто и максимально быстро и пр. разделить, найти общие точки. так, чтобы одну подсистему можно было безопасно перепроектировать в случае необходимости и чтобы отказ одной не повлиял на остальные части. не буду растекаться мыслью по древу, но считаю что любую систему можно спроектировать так, чтобы она сотояла из максимально простых элементов
>понадобятся никогда :) это достаточно разумно спроектированная система.
Вопрос в другом. Нужен ли вообще mysql.>знаете, это как с протоколами OSI
покажите мне где в OSI используется протоколом аналогичный протокол. Не совсем удачное сравнение.>а я считаю что при проектировании надо задумываться о будущем, стремиться сделать
>максимально просто и максимально быстро и пр. разделить, найти общие точки.
Это зависит от системы. Если в процессе развития системы мне приходится менять СУБД или добавлять СУБД это может говорить о не правильно выбраной СУБД или же ошибке проектирования.>так, чтобы одну подсистему можно было безопасно перепроектировать в случае необходимости
>и чтобы отказ одной не повлиял на остальные части.
Не совсем понятно зачем при этом использовать MySQL. Или сразу агрегировать данные не что-то не позволяет?>но считаю что любую систему можно спроектировать
>так, чтобы она сотояла из максимально простых элементов
Систему надо проектировать так чтобы она масштабировалась и видозименялась без особых проблем.
>>понадобятся никогда :) это достаточно разумно спроектированная система.
>Вопрос в другом. Нужен ли вообще mysql.
...
>Не совсем понятно зачем при этом использовать MySQL. Или сразу агрегировать данные
>не что-то не позволяет?
да. мне нужен риалтайм на нижнем уровне
А теперь вопрос почему СУБД MySQL а не агрегация данных в памяти ?PS Использование СУБД MySQL не даcт реалтайм в правильном понимании этого слова.
>А теперь вопрос почему СУБД MySQL а не агрегация данных в памяти
многова-то для RAM. да и проще запрограммировать>PS Использование СУБД MySQL не даcт реалтайм в правильном понимании этого слова.
я понимаю :) если у меня есть простой и очень быстрый инструмент под рукой - молоток. а еще есть молоток, с несколькими наконечниками и двигающейся ручкой... и если я второй молоток правильно настрою (по инструкции и подумавши), то получу такую же скорость забивания, как у первого. поскольку для забивания гвоздей форме 8-ки у меня уже есть специальный электрический лазерный сертифицированный для забивания согнутых в виде 8-ки, 9-ки и 10-ки гвоздей агрегат, у меня останется два инструмента. угадайте, какие?
Btw, а дефолты - решают.Если у вас идиотские дефолты, вашу систему обосрут все с ног до головы.И будут правы.
придурки, больше это никак не обзовёшьни движок майскла не указан, ни конфигурация железок, ни конфигурация софта.
идиотский пиар
Не одидал встретить на opennet такой низкосортный материал
Согласен mysql быстрая база, но pgsql не может настолько отставать в производительности,
надо было немного серьезней отнестись к этому,
сначала бы выбрали спецов для настройки pgsql :|
вот когда разработчики постгреса озаботятся дефолтным тюнингом, тогда и пищщите...
а пока что при все свободе выбора я либо куплю Oracle под Линукс либо буду счаслив с MySQL 5 и ее гениальной простотой.
Неужели у вас и Oracle и MySQL используются с дефолтными настройками?
Гон на постер - вывод из всего прочитанного. Все равно кто знает его не променяет.
>Гон на постер - вывод из всего прочитанного. Все равно кто знает
>его не променяет.а кто не знает - лучше не знать. спокойней спать, калега :) особенно когда знаешь что чтобы перенести БД на другой mysql-сервак нужно просто скопировать файл по rsh. это очень способствует здоровому сну, расслаблению в руках и ногах, холодной голове и крепости члена при занатиях сексом с женой
Это если у вас MyISAM, колллега, а если InoDB, то с простым копированием вы идёте лесом мелкими шажками, Вы людям голову то не морочьте, простым копированием... мдя.
Лично мне не хватает от мускула только внутреннего шедулера, как в Оракле да и в Постгре уже давное реализовано. Ну придётся ждать. Да и кластеризация пока что не супер реализована, много ручного гемора, хотя и достаточно эффективно, ничего не скажешь.
Так что, не знаю, то что победила связка php+mysql в принципе показывает только то, что авторы теста хорошо оттюнинговали данную связку, а остальное взлетали на дефолте.
цитата из документации для тех кто думает что ему морочат голову:Like MyISAM data files, InnoDB data and log files are binary-compatible on all platforms having the same floating-point number format. You can move an InnoDB database simply by copying all the relevant files listed in Section 14.2.8, “Backing Up and Recovering an InnoDB Database”. If the floating-point formats differ but you have not used FLOAT or DOUBLE data types in your tables, then the procedure is the same: simply copy the relevant files.
>цитата из документации для тех кто думает что ему морочат голову:
>
>Like MyISAM data files, InnoDB data and log files are binary-compatible on
>all platforms having the same floating-point number format. You can move
>an InnoDB database simply by copying all the relevant files listed
>in Section 14.2.8, “Backing Up and Recovering an InnoDB Database”. If
>the floating-point formats differ but you have not used FLOAT or
>DOUBLE data types in your tables, then the procedure is the
>same: simply copy the relevant files.Ню Ню. особенно если у теюя с базой активно работают, и если у тебя в binary logs вагон инфы, НЮ НЮ. А ещё, ооочень хорошо, когда у тебя кластер, НЮ НЮ...
По порядку:1) если с базой активно работают, то и myisam не рекомендуется копировать "по живому". innodb ничем в этом от myisam не отличается. Хотя есть способы закопировать консистенто и базу, которая в работе.
2) binary logs в mysql просто хранят информацию о последних insert/updates/deletes и никак не связаны ни с транзакциями ни с консистентностью базы. Причем здесь binary logs вообше? Обьясните, каким образом по вашему мнению binary logs могут помешать копированию.
3) mysql кластер это отдельная storage engine, никак не связанная ни с myisam, ни с innodb. Почему когда я вам пишу про то что innodb _можно_ копировать, вы мне отвечаете про кластер? Каким от тут вообще боком?
>По порядку:
>
>1) если с базой активно работают, то и myisam не рекомендуется копировать
>"по живому". innodb ничем в этом от myisam не отличается. Хотя
>есть способы закопировать консистенто и базу, которая в работе.
>
>2) binary logs в mysql просто хранят информацию о последних insert/updates/deletes и
>никак не связаны ни с транзакциями ни с консистентностью базы.
>Причем здесь binary logs вообше? Обьясните, каким образом по вашему мнению
>binary logs могут помешать копированию.
>
>3) mysql кластер это отдельная storage engine, никак не связанная ни с
>myisam, ни с innodb. Почему когда я вам пишу про то
>что innodb _можно_ копировать, вы мне отвечаете про кластер? Каким от
>тут вообще боком?Можно вопрос:
А нафига мне копировать базу в которой не внесены последние изменения???
Консистентно, опять же, простым копированием???
Да может я и не прав, по поводу InnoDB, однако, по всем рекомендациям самого MySQL AB они не рекомендуют работать с таблицами формата InnoDB простым копированием. (Смотрим книгу "Администрирование MySQL (c) MySQL Press 2005)
Кластер... Вот тут можно сказать только одно - либо я дурак, то же кстати возможно, либо читая документацию я не вижу, что у меня binary logs связаны с механизмом репликации связан как "Отче наш", и все разговоры о том, что это не так, должны быть чётко подтверждены документацией.
Странно, всегда считал, что понимаю как это работает, и оно так, казалось, и работало, однако меня уже 4 человек убеждает в обратном. Как то прям непонятно, да и ни фига не приятно.
>А нафига мне копировать базу в которой не внесены последние изменения???
>Консистентно, опять же, простым копированием???То есть, продолжаем читать между строк, что копируем базу данных при работающем демоне ?
На "slave"-е, который в данный момент получает обновления ?>Да может я и не прав, по поводу InnoDB, однако, по всем
>рекомендациям самого MySQL AB они не рекомендуют работать с таблицами формата
>InnoDB простым копированием. (Смотрим книгу "Администрирование MySQL (c) MySQL Press 2005)Ссылку на документацию приводили? Чем не понравилась?
Онтосительно рекомендаций. Не рекомендуется делать, если не понимаешь что делаешь. Перезапускать сервера тоже не рекомендуется.
>Кластер... Вот тут можно сказать только одно - либо я дурак, то
>же кстати возможно, либо читая документацию я не вижу, что у
>меня binary logs связаны с механизмом репликации связан как "Отче наш",Стоп! Я понял! Вы считаете что репликация и кластер - это одно и тоже. На самом деле это различные вещи, которые и реализуются по разному.
PS кстати binary logs файлы тоже безпроблемно копируются.
>>цитата из документации для тех кто думает что ему морочат голову:
>>
>>Like MyISAM data files, InnoDB data and log files are binary-compatible on
>>all platforms having the same floating-point number format. You can move
>>an InnoDB database simply by copying all the relevant files listed
>>in Section 14.2.8, “Backing Up and Recovering an InnoDB Database”. If
>>the floating-point formats differ but you have not used FLOAT or
>>DOUBLE data types in your tables, then the procedure is the
>>same: simply copy the relevant files.
>
>Ню Ню. особенно если у теюя с базой активно работают, и если
>у тебя в binary logs вагон инфы, НЮ НЮ. А ещё,
>ооочень хорошо, когда у тебя кластер, НЮ НЮ...как-то вы мыслите в терминах Постгреса больше... :)
о да, конечно, предлагалось копировать файлы базы данных при _работающем_ mysqld, желательно очень сильно нагружающем копируемую базу. Как же это я сразу не догадался.> Это если у вас MyISAM, колллега, а если InoDB, то с простым копированием вы идёте лесом
> мелкими шажками, Вы людям голову то не морочьте, простым копированием... мдя.Трудно признать свою неправоту, коллега?
>Это если у вас MyISAM, колллега, а если InoDB, то с простым
>копированием вы идёте лесом мелкими шажками, Вы людям голову то не
>морочьте, простым копированием... мдя.
>Лично мне не хватает от мускула только внутреннего шедулера, как в Оракле
>да и в Постгре уже давное реализовано. Ну придётся ждать. Да
>и кластеризация пока что не супер реализована, много ручного гемора, хотя
>и достаточно эффективно, ничего не скажешь.
>Так что, не знаю, то что победила связка php+mysql в принципе показывает
>только то, что авторы теста хорошо оттюнинговали данную связку, а остальное
>взлетали на дефолте.вам не надоело спорить ради спора?
если вы никогда не проделывали операцию экстренного переноса баз, что я вам буду обьяснять? это можно только почувствовать :). вы со своим постресом и базами на несколько гигов если ваш сервак нагнется будете в полной жопе и до секса у вас (простите за каламбур) руки дойдут еще не скоро после всех этих нудных дампов и ресторов
не знаю как там в MySQL, но в PostgreSQL делаете таким же образом, только копируете в простейшем случае (если tablespace-ы не раскиданы по разным дискам) 2 каталога - tablespace и wal - лог. те же яйца (одна команда), только с tar-ом. те же яйца и для db2 и для Informix и для Oracle ( если базуха не в raw storage ) . Что с успехом проделывалось лично и неоднократно. так что ваше все - мимо кассы.
>не знаю как там в MySQL, но в PostgreSQL делаете таким же
>образом, только копируете в простейшем случае (если tablespace-ы не раскиданы по
>разным дискам) 2 каталога - tablespace и wal - лог. те
>же яйца (одна команда), только с tar-ом. те же яйца и
>для db2 и для Informix и для Oracle ( если базуха
>не в raw storage ) . Что с успехом проделывалось лично
>и неоднократно. так что ваше все - мимо кассы.
[root@xxx pgsql]# find ./data -type d
./data
./data/global
./data/pg_xlog
./data/pg_xlog/archive_status
./data/pg_clog
./data/pg_subtrans
./data/base
./data/base/1
./data/base/17229
./data/base/17230
./data/base/17231
./data/base/17231/pgsql_tmp
./data/base/17232
./data/base/17233
./data/base/1043832
./data/base/3796972
./data/pg_tblspc
./data/pg_log[root@xxx data]# du -d 1
222 ./global
114804 ./pg_xlog
26202 ./pg_clog
122 ./pg_subtrans
418576 ./base
2 ./pg_tblspc
2 ./pg_log
559958 .и где тут wal? куча какой-то херни раскидано по каталогам
>>Гон на постер - вывод из всего прочитанного. Все равно кто знает
>>его не променяет.
>
>а кто не знает - лучше не знать. спокойней спать, калега :)
>особенно когда знаешь что чтобы перенести БД на другой mysql-сервак нужно
>просто скопировать файл по rsh. это очень способствует здоровому сну, расслаблению
>в руках и ногах, холодной голове и крепости члена при занатиях
>сексом с женойХолодные копии можно и в oracle делать.
То-же самое без остановки базы сделайте ;)
>То-же самое без остановки базы сделайте ;)
вы это сказали ради того чтобы что-то сказать?
>>То-же самое без остановки базы сделайте ;)
>вы это сказали ради того чтобы что-то сказать?Я это говорю, к тому, что преимущество таскать по rsh файлы mysql яица выеденного не стоит.
По поводу темы. Хорошо сработал PR отдел MySQL AB в связке с c't Magazine. Можно их с этим поздравить.
Несколько некорректный тест. При простых базах, взаимосвязях между ними и элементарных запросах MySQL уделает всех. Однако как только база становится сложней по структуре,запросы становятся "хитрее", PostgreSQL выходит в лидеры в обработке данных.
Сравнение так же глупо, как сравнивать лошать и верблюда лишь потому что у них по четыре ноги. Они же для разных целей.
>Несколько некорректный тест. При простых базах, взаимосвязях между ними и элементарных запросах
>MySQL уделает всех. Однако как только база становится сложней по структуре,запросы
>становятся "хитрее", PostgreSQL выходит в лидеры в обработке данных.
>Сравнение так же глупо, как сравнивать лошать и верблюда лишь потому что
>у них по четыре ноги. Они же для разных целей.абсолютно верное замечание. тем не менее, я бы предпочел использовать максимально простую и производительную систему для простых вещей (MySQL) и максимально фичанутую (Oracle) для сложной бизнес-логики. Постгрес - ни то ни се.
>>Несколько некорректный тест. При простых базах, взаимосвязях между ними и элементарных запросах
>>MySQL уделает всех. Однако как только база становится сложней по структуре,запросы
>>становятся "хитрее", PostgreSQL выходит в лидеры в обработке данных.
>>Сравнение так же глупо, как сравнивать лошать и верблюда лишь потому что
>>у них по четыре ноги. Они же для разных целей.
>
>абсолютно верное замечание. тем не менее, я бы предпочел использовать максимально простую
>и производительную систему для простых вещей (MySQL) и максимально фичанутую (Oracle)
>для сложной бизнес-логики. Постгрес - ни то ни се.
А покупать Oracle для бизнес логикы вы намеряны ?
>>>Несколько некорректный тест. При простых базах, взаимосвязях между ними и элементарных запросах
>>>MySQL уделает всех. Однако как только база становится сложней по структуре,запросы
>>>становятся "хитрее", PostgreSQL выходит в лидеры в обработке данных.
>>>Сравнение так же глупо, как сравнивать лошать и верблюда лишь потому что
>>>у них по четыре ноги. Они же для разных целей.
>>
>>абсолютно верное замечание. тем не менее, я бы предпочел использовать максимально простую
>>и производительную систему для простых вещей (MySQL) и максимально фичанутую (Oracle)
>>для сложной бизнес-логики. Постгрес - ни то ни се.
>
>
>А покупать Oracle для бизнес логикы вы намеряны ?почему намерЕны? он куплен
"максимально фичанутую" - смешно :) ярко выраженный клиент интегратора, который обещает, что SQL у Вас будет SQLистей, а логика логичнее, если конечно вы ему отдадите своё бабло. Обожаю людей с чужими деньгами, которые хотят не что-то конкретное, а просто "максимально фичанутое". Райское удовольствие их разра... с ними работать.По теме - бред это сравнение. Любая эксклюзивная разработка требует тонкого тюнинга БД в зависимости от характера работы. Postgres в дефолтной конфигурации вообще никакой. Планировщик у него очень капризный и настраивать его нужно под конкретную базу, исходя из статистики работы. Зато сложная выборка из таблицы в 3,5-4 млн записей с кучей полей где GROUP BY делаем по одной части, а ORDER BY делаем по другой, WHERE по остальным полям - занимает у posgres до тюнинга несколько минут!!!, после создание составных индексов "по учебнику" около минуты, после создания индексов в соответствии с "капризами" планировщика, оптимизации весов, тюнингов буферов - менее 50ms. На мускуле подобная табличка обрабатывалась после недельной борьбы за скорость в соответствии с лучшими best practics за 150ms, зато другие операции просто летали, не спорю. IMHO Pg медленнее мускуля в простых запросах, но не более чем на 10%-20%, а не на порядки!!! как написано.
Дефолтные настройки у Pg правильные - они возволяют всего лишь запустить базу чтоб хоть как-то работало, другого и не надо. В качестве примера есть огромные (несколько Тб) астрологические и биологические базы которые довольно шустро шуршат под Pg. Аффторам сравнения - яда, чтобы своими опусами наивных людей не смущали :-)
>"максимально фичанутую" - смешно :) ярко выраженный клиент интегратора, который обещает, что
>SQL у Вас будет SQLистей, а логика логичнее, если конечно вы
>ему отдадите своё бабло. Обожаю людей с чужими деньгами, которые хотят
>не что-то конкретное, а просто "максимально фичанутое". Райское удовольствие их разра...
>с ними работать.жаба давит на моск?
>>"максимально фичанутую" - смешно :) ярко выраженный клиент интегратора, который обещает, что
>>SQL у Вас будет SQLистей, а логика логичнее, если конечно вы
>>ему отдадите своё бабло. Обожаю людей с чужими деньгами, которые хотят
>>не что-то конкретное, а просто "максимально фичанутое". Райское удовольствие их разра...
>>с ними работать.
>
>жаба давит на моск?Dvorkin, мой Вам респект! Один из немногих homo sapiens среди homo haljavikus :)
Позволю себе выразить своем скромное мнение.
С каждым днем посетители когда-то мной уважаемого OpenNet все больше похожи на детей в песочнице, выясняющих у кого совочек больше и ведерко глужбе, и все это на фоне проезжающих мимо карьерных самосвалов.
Еще немного и OpenNet потеснит с первого места anekdot.ru в рейтинге развлекательных сайтов. К сожалению...
сенькс
>С каждым днем посетители когда-то мной уважаемого OpenNet все больше похожи на детей в >песочнице, выясняющих у кого совочек больше и ведерко глужбе, и все это на фоне проезжающих >мимо карьерных самосвалов.
>Еще немного и OpenNet потеснит с первого места anekdot.ru в рейтинге развлекательных сайтов. К сожалению...Простите за оффтоп, но такое мнение проскакивало уже несколько раз, что, мол, OpenNet тупеет, зеленеет и т.д. На самом деле "тупение" аудитории - неизбежное следствие роста популярности ЛЮБОГО проекта. Представьте, что у Вас в форуме ежедневно постят 5 "жестких мачо" и 100 "зеленых новичков". Если популярнасть сайта увеличится, скажем, в 100 раз, туда начнут постить 500 "мачо" и 10000 "новичков". В результате эти 500 просто начнут теряться в огромной зеленой массе, и, если Вы один из тех пяти "мачо", кто стоял у истоков, конечно начнете думать "куда катится мир", "одни неучи вокруг" и т.д., хотя соотношение "мачо" к "новичкам" будет таким же, как и на старте проекта.