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 СУБД, ну и что это изменит?

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