www.it-architect.ru

Думаю, и со мной многие согласятся, нет лучшей СУБД... Лучше та, которую в данный момент лучше знаешь(понимаешь) и используешь.
Сейчас у каждого разработчика сложилось свое представление о выборе той или иной СУБД. На рынке присутствует большое количество предложений... Есть много классов СУБД: одно пользовательские, иерархические, реляционные, объектные, объектно-ориентированные, для мобильных устройств, высокопроизводительные и т.д. и т.п... Кто то пользуется бесплатными БД, а кто то является стратегическим партнером производителя БД, выбрав одну из промышленных разработок.
Думаю более правильным будет постановка вопроса "...для какой задачи выбирают СУБД...". Тогда, в этой теме можно кратко описать задачу, выбранную СУБД, привести доводы в ее пользу.

Абсолютно с Вами согласен, но вот скажите, а что же делать, когда несколько СУБД подходят для моей задачи?
Возьму простой пример: Oracle и MsSql.
Обе сильные, обе многое умеют, различия есть, но такие, которые с минимальное степенью вероятности могут повлиять на мои задачи.
Что же делать? На основе каких характеристик сделать правильный выбор?

на практике критериев 2
1. Бери то, что знаешь
2. Бери то, что уже используется у заказчика.

все остальные аргументы и т.д. - тема с вариациями.

locky писал(а):на практике критериев 2
1. Бери то, что знаешь
2. Бери то, что уже используется у заказчика.

все остальные аргументы и т.д. - тема с вариациями.

Взять то что знаешь, не совсем корректно, так как выбираешь систему на будущее, которую будут развивать много лет.

А что делать, когда нужно сделать реальный выбор и при этом:
1. У заказчика ещё нет никакой системы
2. Ты не ограничен в средствах, фактически как скажешь, так и сделаем

andrey.maslov писал(а):Абсолютно с Вами согласен, но вот скажите, а что же делать, когда несколько СУБД подходят для моей задачи?
Возьму простой пример: Oracle и MsSql.
Обе сильные, обе многое умеют, различия есть, но такие, которые с минимальное степенью вероятности могут повлиять на мои задачи.
Что же делать? На основе каких характеристик сделать правильный выбор?

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

Перечисленные БД давно присутствуют на рынке. Существует большое количество реализованных проектов с их использованием. Обе хорошо и плохи по своему.
Вопрос может быть и в архитектуре самого разрабатываемого приложения (проекта). Можно работать только с одним брендом БД, а можно реализовать выбор СУБД в самом приложении. И опять, это можно сделать заранее при составлении ТЗ или реализовав в приложении собственный промежуточный слой работы с БД.
Я знаком с разработчиками, которые писали свой продукт и предлагали клиенту выбор той или иной БД (в основном решения для web платформы), а также с компаниями которые выбрали один стандарт БД и использовали его особенности и преимущества в своем проекте (деловое ПО). Мне ближе по духу именно второй вариант, т.к. он проще в организации сопровождения разрабатываемого продукта и сопровождения непосредственно самой СУБД.

locky писал(а):на практике критериев 2
1. Бери то, что знаешь
2. Бери то, что уже используется у заказчика.

все остальные аргументы и т.д. - тема с вариациями.

Абсолютно солидарен! Нельзя одинаково хорошо знать всё о всех СУБД, всех производителей. Это просто недостижимо.
Есть СУБД которые постигаешь годами плодотворной работы с ней

Прошу прощения за возможную некомпетентность , но у меня в моей практике часто встает вопрос не выбора производителя SQL баз, а именно архитектурный момент (буквально недавно я решил вопрос выбора СУБД именно в пользу документо-ориентированности и отказался от SQL вообще, правда и проект то особо проектом не назовешь ). Я заметил что в большинстве случаев под понятием СУБД подразумевается SQL база, хотя имеется большой выбор именно в архитектурном плане: документо-ориентированые системы (яркий тому пример mongo с его JSON нотацией и колоночным хранением данных ), просто NoSQL, и пр. - однако подход "бери что знаешь" - не самый наверное лучший, так как приводит к тому что проект при своем развитии может прийти к состоянию, что текущая БД просто не справляется с возложенными на нее ф-ми. (в нашем проекте который развивается мягко говоря давно, мы уже меняем 3ю СУБД: interbase->firebird->PostgreSQL). Может есть у кого мысли каким образом стоит выбирать БД чтобы подобное не повторилось? А то что нет лучшей СУБД - правильно, каждому свое

Scotty писал(а):Прошу прощения за возможную некомпетентность , но у меня в моей практике часто встает вопрос не выбора производителя SQL баз, а именно архитектурный момент (буквально недавно я решил вопрос выбора СУБД именно в пользу документо-ориентированности и отказался от SQL вообще, правда и проект то особо проектом не назовешь ). Я заметил что в большинстве случаев под понятием СУБД подразумевается SQL база, хотя имеется большой выбор именно в архитектурном плане: документо-ориентированые системы (яркий тому пример mongo с его JSON нотацией и колоночным хранением данных ), просто NoSQL, и пр. - однако подход "бери что знаешь" - не самый наверное лучший, так как приводит к тому что проект при своем развитии может прийти к состоянию, что текущая БД просто не справляется с возложенными на нее ф-ми. (в нашем проекте который развивается мягко говоря давно, мы уже меняем 3ю СУБД: interbase->firebird->PostgreSQL). Может есть у кого мысли каким образом стоит выбирать БД чтобы подобное не повторилось? А то что нет лучшей СУБД - правильно, каждому свое

Я бы выбирал СУБД, которая 100% в дальнейшем будет развиваться и поддерживаться.