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 нравиться тем, что в ней много удобств и достоинств и нет недостатков ... в тех областях, где мы ее применяем. И что из этого можно понять ? :)
Это пусть автор пытается понять. Он же спросил, не я.

Alexey Rovdo ASCRUSДля начала автору неплохо бы уточнить область применения СУБД, тогда и ответов больше будет. И для каждой области применения каждая конкретная СУБД будет иметь свои достоинства и свои недостатки, не бывает СУБД, которые для всех поставленных задач идеально подходили. Я во всяком случае еще не встречал таких.

f_w_pПодходить к выбору СУБД только от задачи, наверное, тоже не совсем правильно. Так можно на крупном предприятии породить целый зверинец СУБД. А админам потом расхлебывай:-(

Вот опять. Вопрос ведь не в том как надо подходить к выбору СУБД или какую СУБД лучше выбрать для той или иной задачи (области). Вопрос в том, как на практике (в реальной жизни) происходит этот выбор и какие факторы на этот выбор имеют наибольшее влияние (заметьте - имеют влияние , а не должны иметь влияние )?
У профессионалов выбор происходит как надо.
У остальных - как повезет (многие могут рассказать, как им повезло или не повезло :)

ArtaСпасибо тем, кто понял меня правильно :)
Я ведь не спрашиваю, как МНЕ выбрать СУБД. Я хочу узнать как ВЫ выбираете. Если это зависит от цели использования, то, как тут уже говорилось, критерием выступает функциональность. Значит, для Вас это главный аспект при выборе. Еще для кого-то, может, очень важно наличие техподдержки, а кому-то она нафиг не нужна, так как он собаку съел, и не одну, работая на данной СУБД, и на другую переходить не собирается. А если Вы работаете на том, что правая пятка Самого Главного Директора пожелала, то это уже другая ситуация. Поскольку выбираете не вы. :)
Какой-то детский подход.
Функциональность есть функциональность, вещь в себе, это не критерий. Критерием может служить наличие необходимой функциональности.
Причем если ничего не найдется или найдется слишком дорогая СУБД, придется пересмотреть требования к ней.
В каждом проекте есть несколько критериев, выбор алгоритмизировать до конца не получится.
Даже если выбирать СУБД просто для самостоятельного изучения, и то критерии могут иметь различный вес - исходя их того, для чего Вы ее беретесь изучать.

Arta[quot DogenКакой-то детский подход.
Функциональность есть функциональность, вещь в себе, это не критерий. Критерием может служить наличие необходимой функциональности.

Хорошо, пусть будет "максимальное соответствие функциональности поставленной задаче". Но ведь Вы уже говорите, что вторым критерием становится цена, и в случае, когда она слишком высока, будут рассматриваться другие варианты, возможно, менее подходящие для решения задачи, зато доступные. Это как раз и есть ответ на мой вопрос :)[/quot]
Какой-то чуть менее детский подход.
Вам что-нибудь проектировать приходилось?
Для меня первым критерием в одном из проектов была надежность (в том числе и простота эксплуатации, и наличие хорошей документации и т.д.)
Ну и что?
Был бы это веб-сайт, а не система учета, были бы на первом месте другие критерии.
Есть сроки проекта, есть бюджет, есть заявленные технические и стоимостные характеристики продукта - вот в эти рамки надо укладываться. Теперь ясно? Что вы из критериев самоцель-то делаете!

Alexey Rovdo Dogen Был бы это веб-сайт, а не система учета, были бы на первом месте другие критерии.
Есть сроки проекта, есть бюджет, есть заявленные технические и стоимостные характеристики продукта - вот в эти рамки надо укладываться. Теперь ясно? Что вы из критериев самоцель-то делаете!

В действительности никто не спорит с тем, что сами критерии выбора СУБД зависят от первичных параметров проекта. Но и здесь вопрос сводится к тому как они они на ваш взгляд от этого зависят (т.е. для таких проектов - такой порядок приоритетов, для других другой). Вот вы пишете про сроки, бюджет и технические характеристики. Значит ли это, что при выборе СУБД для проекта (будь то веб-сайт или система учета) вы применяете эти критерии именно в названном порядке? Т.е. следующим образом:
1) Наличие в составе СУБД (или в виде отдельных продуктов) специальных средств (методик) разработки, позволяющих реализовать проект в заданные сроки.
2) Возможность удовлетворить поставленные технические требования в рамках выбираемой СУБД и средств разработки.
3) Цена разработки, цена СУБД и цена средств разработки.

Имеет ли место в вашей практике этот порядок? Уверен, что найдутся и другие ситуации, когда на первое место ставится, например, цена. Сталкивались ли вы с такими (или иными) ситуациями? И еще раз обращаю внимание на то, что гораздо интереснее узнать то, как есть, а не то, как должно бы быть.
Хорошо, рассмотрим живые проекты. Критерии в порядке убывания значимости.
1. Интернет-магазин.
- наличие порта FreeBSD
- простота администрирования
- какие-никакие знания конкретной СУБД, имеющиеся у персонала
- способность поддерживать БД определенного размера (небольшого - сотни мег.)
- простота интеграции магазина в КИС (читай, та же СУБД что и в других системах)
- бесплатность (могли бы и купить, смысла в этом однако же нет)
2. OLTP.
- способность переварить базы объемом в 1...5 GB
- наличие версии для Linux
- удобство и время выполнения бэкапа/восстановления
- простота администрирования
- возможно более полное соответствие стандартам SQL-...
- какие-никакие знания конкретной СУБД, имеющиеся у персонала
- бесплатность (могли бы и купить, смысла в этом однако же нет)
3. СЭД.
- способность переварить базы объемом в 5...25 GB
- наличие версии для Linux
- безглючная работа с блобами
- наличие полнотекстовых индексов

Ну и что Вам дают эти перечни, кроме удовлетворения любопытства?
Чего Вы делаете упор на RAD, я не понимаю. Если не использовать специфические особенности SQL-серверов, то не имеет особого значения какую СУБД использовать для очередной примитивной системы. А для сложных систем основными критериями будут надежность и функциональность. Но ведь чуда все равно не случится, и чем-то придется поступиться.

vybegallo Alexey Rovdo Dogen Был бы это веб-сайт, а не система учета, были бы на первом месте другие критерии.
Есть сроки проекта, есть бюджет, есть заявленные технические и стоимостные характеристики продукта - вот в эти рамки надо укладываться. Теперь ясно? Что вы из критериев самоцель-то делаете!

В действительности никто не спорит с тем, что сами критерии выбора СУБД зависят от первичных параметров проекта.

Неверно.
Пока в организации бардак, каждый начальник выбирает по-своему. Потом приходит CTO, назначает "стратегическую платформу" из числа большой тройки-четверки-пятерки, и все новые проекты выполняются на этой платформе. Функциональность конкретной задачи никого не.. волнует.
По какому признаку для платформы выбирается один продукт из Большой Тройки (Oracle/MS SQL/DB2) или Пятерки (те же + Sybase + Informix) - другой вопрос.
Ну и что?
Ну выбирают СУБД в качестве стратегической платформы, так это всего лишь проект большего масштаба.
Ну рассмотрю я не 5 а 8 СУБД, ну и что это изменит?

vybegallo Dogen vybegallo Alexey Rovdo Dogen Был бы это веб-сайт, а не система учета, были бы на первом месте другие критерии.
Есть сроки проекта, есть бюджет, есть заявленные технические и стоимостные характеристики продукта - вот в эти рамки надо укладываться. Теперь ясно? Что вы из критериев самоцель-то делаете!

В действительности никто не спорит с тем, что сами критерии выбора СУБД зависят от первичных параметров проекта.

Неверно.
Пока в организации бардак, каждый начальник выбирает по-своему. Потом приходит CTO, назначает "стратегическую платформу" из числа большой тройки-четверки-пятерки, и все новые проекты выполняются на этой платформе. Функциональность конкретной задачи никого не.. волнует.
По какому признаку для платформы выбирается один продукт из Большой Тройки (Oracle/MS SQL/DB2) или Пятерки (те же + Sybase + Informix) - другой вопрос.
Ну и что?
Ну выбирают СУБД в качестве стратегической платформы, так это всего лишь проект большего масштаба.
Ну рассмотрю я не 5 а 8 СУБД, ну и что это изменит?

Функциональные возможности СУБД при таком выборе практически не интересуют.
А что же тогда интересует?