> Сравнивать оракл > и постгрес смысла не имеет, а вот постгрес и эскулайт - вполне. +1000 Для каждого продукта есть своя область применения. «Универсальность» не говорит о применении всегда и во всем (даже возможность этого применения). Возьмем для примера запрос из жизни – получить данные на/за определенный период, дополнительные условия для простоты ставить не будем. Создадим вьюшки. Имеем: небольшую БД на пару десятков Гб, искомые данные есть объединение нескольких таблиц (ну не обрывки же нормализованных таблиц получать). В операции принимают участие 5-6 таблиц, часть «легких» (справочных) часть продуктивных (в среднем по 10 млн. записей на таблицу). И так, говорим – «нам надо выбрать из середины 50 записей» (утрировано конечно, но что бы не парится с датами). Предусловия: Есть СУБД с полностью идентичной структурой (максимально возможно с учетом разных СУБД) Firebird, PostgreSQL, MySQL, DB2, MS SQL, Oracle – все версии «свежие» (на лето 2009 года). Все (за исключением MS SQL, которая имеет версию 2008 и работает на таком же железе но под управлением Windows 2008) работает под управлением Debian на серверном железе (в стойке). Клиенты отсутствуют (за исключением машины с которой запускаются тесты). В общем, цель поста не «официально» показать результаты, ибо нет возможности сейчас эти цифры тут выложить. При первом запросе самым медленным оказался MS SQL самым «быстрым» Oracle. При повторных запросах, в лидерах остались PostgreSQL & Oracle & Firebird (!!!). При наложении условий на вьюшки Firebird отпал, PostgreSQL давал сравнимые результаты только со второго-третьего раза того же запроса (относительно Oracle). В общем, разница по времени составила в среднем в 100 раз между самым «медленным» и самым «быстрым» результатом. DB2 «выпала» потому, что, подозреваю что дело не в СУБД а в руках что её ставили, так что не стоит обращать внимание на участие этой СУБД в «тестах».
Таким образом, есть определенные области использования, есть определенные задачи и наборы данных, есть условия при которых будут работать с этими данными. В общем, это целый комплекс требований, и сам выбор СУБД не так тривиален. Но четко можно сказать, для «сигмента в n данных – использовать Firebird, MySQL, SQLite , MS SQL, PostgreSQL …», «сигмента в n*k данных – использовать MS SQL, DB2, Oracle, PostgreSQL …», «сигмента в n*2k данных – использовать DB2, Oracle, PostgreSQL …», «сигмента в n*ak данных – использовать DB2, Oracle» А попытки натянуть коротенькое одеяло на все свои хотелки и условия – ни к чему хорошему не приведёт, последующий переход намного сложней чем первичное проектирование. Не стоит притягивать свою упертость и утверждение «универсальная» для всего.. :) Оперировать миллионами пользователей и терабайтами данных так же не стоит. Это не бойцовский ринг, на практике таких данных нет (если вдруг где то есть – то либо аналитики там стреляются теперь, либо таких аналитиков надо гнать). Не в силу их отсутствия, а в силу нормального проектирования – мы же в этом случае о промышленном использовании говорим. -- С уважением, Виктор mailto:[email protected] -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
