Каковы факторы в выборе определенной Системы управления базами данных? [закрытый]

Если парадигмы одинаковы, это также вопрос разделения рынка. (Пропущено ли это?!?) В противном случае ответ Петра является значительным.

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

What are factors to choose a specific DB management system ?

• Лицензирование
• Платформа
• Производительность
• Поддерживаемый язык программирования
• и т. Д. И т. Д.

Заметно отсутствие, например, ориентированные на столбцы (LucidDB), независимые от платформы (derby), в памяти (hsqldb, хотя и derby здесь тоже подходит) и, возможно, другие базы данных, в зависимости от их ключевых свойств.

Системы баз данных также предлагают различные парадигмы. Например, MySQL или MSSQL - реляционные, db4o - объектно-ориентированные, а MongoDB - документо-ориентированные.

По большей части, если вы пишете для рынка РСУБД / SQLish, вам, вероятно, следует задать вопрос номер один: «О чем я уже знаю? Что знают мои сотрудники?» Если у вас есть на это ответ, то вам, вероятно, следует сначала выбрать этот SQL-движок. Мой компьютерный фанат базы данных съеживается от этого ответа, но правда в том, что если ваши разработчики не входят в крошечную часть, которая все равно действительно получает реляционные базы данных, вы собираетесь использовать ту же глубокую колею стандартных ошибок базы данных, что и все остальные, и основные вопрос будет в том, сможете ли вы заставить вашу систему работать достаточно быстро.

Это, вероятно, верно, если вы проглотили кувшин любимого напитка NoSQL, поскольку и там вам нужно выбрать то, что вы понимаете.

Однако, если вы уже в состоянии понять все эти различия, тогда вы поймете, что ответ - «это зависит от обстоятельств». Обычные четыре измерения сводятся к следующему: скорость выполнения для заданного профиля рабочей нагрузки (это вопрос того, хороша ли база данных для конкретного типа проблемы: некоторые из них быстрее для поиска, например, где другие лучше при высокой степени параллелизма. пишу); Соответствие SQL в целевых областях (например, Oracle имеет забавную, то есть неправильную, обработку NULL, MySQL повсюду на карте, Postgres переносит идентификаторы без кавычек в нижний регистр); денежные затраты как сразу, так и в долгосрочной перспективе (включая требования к оборудованию, затраты на найм людей, лицензии); и, возможно, функции, которые вам нужны (если вам нужен Oracle RAC, вам нужно купить Oracle).

«Этот ответ на самом деле не отвечает на вопрос« почему », он просто отвечает на вопрос« кто »».

Верно, но я предполагаю ответ на « почему «могло быть так много» тех, кто все думали, что могут сделать это «лучше, чем другие».

С «лучше», имеющим значение заполнения пробелов, которые выбрал конкретный «кто»:

• почти водонепроницаемая гарантия успеха чтения через блокировку MVCC, в отличие от более традиционных двух- фазовая синхронизация.
• без комиссии, в отличие от комиссии в миллион долларов
• простой интерфейс с языком XYZ, которого нет у других
• ...

Моя личная любимая проблема - поддержка CREATE ASSERTION. Он входит в стандарт SQL с 1992 года, и никто из крупных слонов не знает, как его поддержать. Я делаю.