ArtaХотелось бы задать такой вопрос: какие СУБД Вы предпочитаете использовать, а главное - почему? Критерии выбора, достоинства, которые для Вас наиболее значимы. А заодно вопрос о недостатках - что Вас больше всего не устраивает в используемых Вами системах. Одним словом, значимые факторы при выборе.

Критерии выбора (порядок в зависимости от задачи может меняться)
- адекватность реализуемого функционала требованиям проекта (ну вот например не нужны хранимые процедуры, и список серверов сразу пересортируется)
- надежность (безглючность, удобство резервного копирования и восстановления)
- скорость работы с модельной БД (время выполнения типовых запросов)
- требования к дисковому пространству и количеству процессоров (для конкретного класса задач)
- наличие хорошей документации, книг (для первоначального изучения), комьюнити (у mySQL оно традиционно убогое, например :)
- масштабируемость
- положение фирмы-разработчика на рынке

Основные недостатки виденных серверов:
interbase (старые версии) - тормозной
MS SQL - жрет ресурсы
mySQL - недостаточно функционален, плохой оптимизатор (в части вложенных запросов точно плохой :)
Sybase ASA - медленее mySQL и MS SQL, менее распространен
Oracle, DB2 - не приходилось использовать на практике, потому ругать не стану. В принципе мешало этому личное мнение о сложности установки и освоения.
hsqldb - сейчас это игрушка для десктопных задач, но прикольная :)

Поскольку говорилось о СУБД, а не только SQL-серверах:
ZODB (из поставки zope) - доморощенное и глюкавое хранилище объектных данных, самый большой минус в том что используют его мало, потому и сырое
VFP - отвратительная реализация контейнера БД (файл dbc то бишь), глючный процессор SQL
Paradox - падает в разы чаще чем фокспро (со времен ДОС не использовал)
Cache - не пробовал и не собираюсь (ну тут причин много)

Диченко Dogen
VFP - отвратительная реализация контейнера БД (файл dbc то бишь), глючный процессор SQL


Тебя никто не заставляет использовать контейнеры БД. Практики вообще БД в фоксе не используют, вся работа только с временными таблицами
Я с Вами, товарищ, свиней не пас. Можно еще стажем практического использования фокспро померяться, тоже аргумент.

Вопрос был про СУБД, а не про средства разработки приложений, что ты опять [censored]. Я прекрасно понимаю что на VFP можно легко и быстро писать толстого клиента. Более, того, я, похоже, продвинулся малость дальше тебя и - страшно сказать - по мере сил ухожу от использования ODBC при коннекте к серверам данных. Мешает довести сей процесс до логического конца исключительно приобретенная за годы обучения в высшей школе лень. Да и от фокспро уходим мы уже, небезуспешно.

ASCRUS Steppenwulf Dogen Sybase ASA - медленее mySQL и MS SQL, менее распространен

что значит медленнее??? что именно в ASA медленнее?
Имеется ввиду наверное 5-ая версия 90-х годов, которая еще и на QNX пахала и расчитана была на небольшое кол-во подключений. А вот насчет ASA 9.0.2, ее распостраненности по миру и скорости я бы не рекомендовал делать таких вот необоснованных утверждений, а для начала посоветовал бы почитать ее родной BOL по главам, посвященных механизмам работы блокировок, индексов, оптимизатора, временных таблиц, кэшей данных, индексов и планов запросов, погонять лично на Win/Unix серверах на тяжелых запросах и больше не говорить такое :)
Задел :))
Была это 6-я версия.
Однако товарищ который спросил навряд ли в ближайнее время будет тяжелые БД на *nix эксплуатировать...

MX-ALEX ASCRUS авторОднако товарищ который спросил навряд ли в ближайнее время будет тяжелые БД на *nix эксплуатировать...
Да хоть какие базы, хоть какие СУБД ... лишь бы программировать граммотно умел

достали..
грамотно - с одним м пишется ..
а вот автор топика ни адной грамматической ащипки не сделал!!!

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


"пока вы смотрите свой телевизор, инопланетяне через него трахают вам мозги"

ArtaНасчет "даром". А жалко? :)
а я, между прочим, довольно подробно отписался

а потом сообразил, что вопрос слишком общий - Вам что, расписать как выбирать СУБД для OLTP, ECM, ГИС, биллинга, реестра пенсионеров, интернет-магазина...

Александр Гoлдун Dogen
Sybase ASA - медленее mySQL и


На простых селектах к одной таблице даже Oracle медленнее MySQL (по утверждению очень многих, сам не проверял). Если же логика чуть сложнее SELECT * FROM table_name WHERE id=10, то MySQL нервно курит в сторонке (опять таки, информация от третьих лиц). Я уж молчу про транзакции, процедуры, триггера и т.п.
Dogen
MS SQL,

Спорно. Особенно если сравнивать последние версии обоих продуктов.
Dogen
менее распространен

У нас в России - да. Тут самые распространенные - MSSQL - потому что 1с и MS, IB - потому что Delphi, Oracle - потому что круто.
За рубежом - не факт. Если нет проблем с английским, то получаешь очень обширное сообщество пользователей, можно пообщаться с множеством профессионалов и даже с разработчиками ASA, повлиять на его развитие.

Ну почему от третьих :))
В mySQL дурацкий механизм обработки подзапросов, он тормозит невозможно. И вряд ли его быстро вылечат, судя по нынешним темпам разработки mySQL. Про процедуры и триггеры я тоже молчу, ну так mySQL для примитивных задач используется обычно. На них и сравнивал.
Последние версии я не тестировал. Собираюсь, однако.
Про ASA - ну это мне напоминает ситацию с Apple. Их тоже много за рубежом.

Но вот чего Вы не хотите ответить автору топика :)) Товарищ про автомобиль неслабую аналогию привел, вот давайте в таком аспекте.

ASCRUS авторНо вот чего Вы не хотите ответить автору топика :)) Товарищ про автомобиль неслабую аналогию привел, вот давайте в таком аспекте.
А толку тут расписывать достоинства выбранной СУБД ? Нам, например, ASA нравиться тем, что в ней много удобств и достоинств и нет недостатков ... в тех областях, где мы ее применяем. И что из этого можно понять ? :)
Это пусть автор пытается понять. Он же спросил, не я.