Насколько совместимы механизмы БД на уровне SQL?

Question

Допустим, я хотел иметь приложение, которое могло бы легко переключать БД на серверной части.
В основном я рассматриваю SQL Server в качестве основного бэкэнда, но с гибкостью, позволяющей перейти на другой механизм БД. Firebird и PostGreSQL, кажется, имеют (из моей краткой экскурсии по Википедии) самое распространенное с SQL Server (плюс они бесплатны).

Насколько похожи настройки, доступ, запросы и т. Д. БД для Firebird, PostGreSQL и MS SQL Server?

Answer 1

К сожалению, SQL сильно различается у разных поставщиков. Почти невозможно написать все, кроме самого тривиального SQL, для выполнения на нескольких РСУБД, и тогда вы окажетесь на территории с наименьшим общим знаменателем. Гораздо лучше использовать уровень абстракции для обработки по крайней мере соединения с базой данных (включая доступ, отправку запросов) и либо ORM для обработки самого SQL, либо SQL для каждого поставщика.

Если вы хотите посмотреть, как они различаются - хорошими примерами являются автоматически увеличивающиеся идентификаторы и получение идентификатора последней вставленной записи.

Answer 2

Я работал над одним проектом, в котором было абсолютным требованием поддерживать множество баз данных, включая, по крайней мере, Access, SQL Server и Oracle.

Так что я знаю, что это можно сделать. В основном DML (SELECT, UPDATE, INSERT ...) одинаков, и, конечно же, у нас не было серьезных проблем с его работой во всех базах данных - только случайные неприятности. В то время MySQL был исключением, поскольку он просто не был достаточно способен.

Мы обнаружили большинство различий в DDL, но с правильной архитектурой (которая у нас была) это было несложно исправить.

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

Это упростило задачу, потому что мы избегали использования автоинкремента для полей идентификаторов, сложнее думать об уникальных ключах - но лучше в долгосрочной перспективе.

Answer 3

Как указывают другие ответы, СУБД сильно разнятся, когда вы выходите за рамки базовых элементов SELECT / INSERT (а иногда даже там).

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

В частности, стоит взглянуть на популярные ORM (Hibernate, nHibernate и т. Д.). Они обычно предлагают независимость от БД как своего рода побочный эффект. По крайней мере, Hibernate также имеет специальный язык запросов, который будет автоматически переведен на SQL для используемой вами СУБД.

Answer 4

Что ж, CRUD-компоненты должны быть везде одинаковыми, но если вы создаете что-то сложное, вам, вероятно, захочется использовать триггеры и хранимые процедуры, и именно здесь совместимость становится низкой. Написание приложения, независимого от СУБД, обычно означает перемещение большей части бизнес-логики за пределы базы данных, поэтому наличие трехуровневого приложения, IMHO, является обязательным в таком случае.

В качестве альтернативы, вы можете использовать некоторую библиотеку-оболочку, которая работает как уровень абстракции, но я пока не вижу такой, которая способна правильно выполнять эту работу в ряде СУБД. Конечно, это также зависит от языка программирования, который вы используете.