Пара поправок:
1) PostgreSQL есть и для Windows!
2) Способ доступа - почему нет JDBC-драйверов как категории? Принципиально для J2EE проектов!

Несколько лет назад делал сравнительный тест MySQL vs Interbase
табличка с 3 целочисленными полями, проиндексирована.
Клиент в случайном порядке делает операции случайной выборки, вставки, обновления и иногда удаления.
Таблица быстро растет до 800000-1000000 записей.
Число шагов фиксировано, около 1000000.
Учитывалось время.
Так вот. MySQL давно закончил, а Interbase все работал и работал как энерджайзер. Я так и не дождался.
Впоследствие я еще пару раз делал подобные пробы на готовых базах.
Копировал их в Interbase и сравнивал. MySQL всегда многократно обгонял Interbase.
Поставте MySQL 5.* на тоже железо, что и Oracle так он и его порвет как тузик грелку.
На работе основные базы(террабайты) на Oracle, может другие писают кипятком, но у меня, только отрицательные впечатления от этого тормоза. Железо там не хилое(на миллионы баксов), памяти немеряно.
Поменьше базы(гигабайты), на MS SQL. Довольно быстрая, но субъективно не быстрее MySQL. Не сравнивал на тестах. Но очевидные минусы - намного тяжелее, требует больше памяти, проприетарная, Windows.
Что касается размеров баз, так MySQL справляется и с террабайтными базами и с миллиардами записей и с десятками тысяч таблиц, если железо и ось позволяют. Все фичи промыщленных СУБД у MySQL уже имеются, недаром Oracle купил его InnoDB и собирается включить в свою СУБД.

Если все так, то почему здесь нет ни одного теста где MySQL хоть как-то бы присутсвовал (не говоря уж о победе)?


Ну так возьми реальную продакшн базу и перенеси ее на MySQL, и посмотри как быстро он будет работать с этой базой  потому как тестовая база на 3 таблички и запросы по первичному ключу, это еще не показатель. Вот когда тебе надо будет в одном запросе объединить 10 таблиц, по паре миллионов записей в каждой, вот тогда можно говорить о реальной нагрузке.

Да тормоза сами по себе, еще ни о чем не говорят. Кто сказал, что СУБД хорошо настроена и база хорошо спроектирована?


Oracle не покупала InnoDB, а пыталась купить MySQL. И включать этот код в состав своей СУБД они не будут, по многим причинам.

Его просто не тестировали.

Не дадут, слишком критичные сервисы там крутятся, нет ресурсов и времени. А свои проекты я предпочитаю реализовать на MySQL или, в угоду заказчику, на MSSQL.
Будет железо, тогда сравню.
Просто я хотел сказать, что господа бизнесмены и начальство не заморачиваются по этому поводу, а закупают и ставят всё по признаку престижности - всё самое "крутое". Может MySQL и справился бы с их задачей, но он не престижен. Именно поэтому, мало примеров больших баз на MySQL. Не потому, что он не может, а потому, что Клиент не хочет. Вложение в престижный дорогой софт увеличивает стоимость компании, а также внутрикорпоративный престиж и зарплату тех кто его внедряет и обслуживает.


Да это так. Базы часто проектируют и настраивают не карашо.
Только я вообще не видел не тормозных баз на Oracle, а также не тормозной Oracle с пустой базой на доступной чистой машине. Пусть мое мнение субъективно, но я делаю выбор на основании своего личного опыта.

Вот и я о чем же. Спецификации тестов открыты, и попадание в этот список очень престижно для компании. Почему MySQL AB не озаботились провести тесты, ведь база бесплатная, и по части Price/tpmC они могли бы посоревноваться?

Кстати а MySQL работает на Power и Ultra Sparc?

В начале темы дан рейтинг СУБД по различным параметрам. А как выстроятся основные рассмотренные СУБД по параметру "Скорость работы"? Кто подскажет? 

Скорость работы сама по себе, параметр абстрактный. Не зная, что за данные, какое оборудование используется, характеристики запросов и т.д., нельзя ничего сказать.

В связи с новыми выпусками MS SQL (2005) считаю, что стоимость программирования на MS, всётаки ниже. Оптимизатор MS SQL (2005), несравненно выше, чем у Oracle. Поэтому, для программирования этогго монстра (Oracle), нужен шышкастый (наученый горким опытом) ботаник, который будет оптимизить каждый запрос одного и тогоже представления. И для реализации (проектирования) некоторой сложной системы на MS потребуется создавать меньше объектов, да и размер "кода", имхо, будет меньше. Или у кого-то есть иной опыт?
Может кто и ругается на глючность мелгомягких, но в основном нарывался на глючность Oracle, как его провайдеров (всё таки клиенты чаще на платформах MS) так и самого сервера (но, хоть и вылетала сессия (критически, скорре из-за глючного плана запроса), слава богу, сервер не падал).

Стоит ли добавить в список оценок "Оптимизатор запросов"?
Не знаю, как остальные БД, но MS, как мне кажется, должна стоить на самом верху.

Если у тебя есть конкретные факты: на таких-то таблицах, таких-то данных, и таком запросе, оптимизатор Oracle делает то-то, а оптимизатор MS SQL то-то, то создай новую тему и опиши это там. А если нет, то не надо тут разбрасываться ничем не подтвержденными утверждениями, если хочешь иди в раздел Религиозные войны и там пиши, что хочешь.
А насчет опыта - у меня есть противоположный опыт, и что с того? Это ничего не доказывает.


Не стоит. Тот кто хорошо себе представляет, что такое оптимизатор запросов и что он может дать - выберет СУБД и без этого FAQ. А тому кто не знает, это ничем не поможет.

Господа ну зачем же вы развели здесь всю эту демагогию.
Прежде всего каждый из нас использует в своей жизни то к чему смог в свое время адаптироваться
и не надо бедных новичков зазывать возгласами "А моя СУБД лучше"
За редким исключением я так и не нашел, адекватного подхода к разъяснению о СУБД и базах данных.

Уважаемый Vit, тем не менее хочу заметить что вы начали обсуждение темы не с той стороны.
Тема правильная, но увы полной сути своей она так и не достигла.
Выбор метода хранения данных последний этап разработки систем.
1. Постановка задачи
2. Реализация алгоритма
2.1. Серверная часть
2.2. Клиентская часть
3. Факторы риска (включая взлом и разрушение структуры, в том числе и физические факторы "железа")
4. Планирование схемы данных (включая факторы риска)
4.1. Выбор типа подключения (ODBC, JDBC, DirectConnect)
5. А вот здесь можно подумать об альтернативах, какой-то СУБД или БД на основе нашего тех. задания, главное чтобы могла удовлетворить на 100%, излишки допускаются, но это финансовые потери.
А уж тут выбор делает ответственный за разработку, а не мы на форуме, ибо потом ответственность несет он, а не мы.

Не забывайте, пожалуйста, о том, что вы никогда не узнаете сколько "весит" ваша БД, сколько пользователей ее будет использовать и как они будут это делать, без предварительного анализа, который надо уметь делать, иначе в один прекрасный день вы придете в тупик.

И учить новичков надо не 5-му пункту а первым 4-ем, чтобы они могли понять, чего же на самом деле им требуется, что они могут и чем ограничены.

З.Ы. В начале своей трудовой деятельности мне пришлось изучить ASA Sybase, но это не принципиально, это диалект SQL и иначе я его не воспринимаю, позже я столкнулся и с Access и с MySQL и с MS SQL, и много с какими другими БД и СУБД, ничего сложного в переходе с одного диалекта SQL на другой нет, все они в той или иной мере подчиняются стандарту SQL/99, остальное "фичи" производителей.
З.З.Ы. Все мы начинали с RECORD-подобных БД в ВУЗ-ах ;-), мы должны совершенствоваться.

Уважаемые, друзья, вопрос в выборе СУБД для такой задачи:

Примерный размер: до 10000 записей
Кол-во пользователей: до 100
Желательно бесплатная
под Windows
с небольшими требованиями к железу.
Также необходим задел на будущее (примерно 5 лет).

Мой выбор остановился на Interbase (Firebird) и MySQL.

Кто что посоветует? Может кто-то расширит мой список?

Заранее спасибо.

Постгрес тоже подходит под эти требования. 

А в принципе они не совсем четко сформулированы. 10000 во всех таблицах вместе взятых или в одной? Сколько всего таблиц? Будут ли там храниться "тяжелые" данные типа картинок, видео и т.п.? 100 подновременно или всего? И сколько тогда одновременно (в пике)? Характер запросов?


А ты можешь научить новичков первым 4-м пунктам?  

Спасибо LSD за ответ.
10000 записей - лишь примерный порядок, наверное, во всех таблицах. Сколько примерно таблиц будет я еще не знаю.
Скорее всего там будут храниться какие-то тяжелые данные.
Кол-во пользователей: 100 - это всего лишь порядок. одновременно - не больше 30.
Характер запросов? Не знаю.

Меня больше интересует что все-таки выбрать: MySQL или Interbase?

Да в принципе база маленькая... пойдёт любая... Если под винду и языками от Борланда то наверное удобнее будет работать с Interbase, а если под php+Linux то MySQL

черт, я новичек и совсем запутался уже в этих СУБД.
помогите.

какую базу выбрать, если:
система Windows
среда программирования C++ Builder

есть также основа БД, которая сделана в MS Access, т.е. ее нужно будет интегрировать в новую БД.

че ж мне тогда выбрать?

и какая хорошая литература есть по вашим вариантам?