Насколько совместимы движки БД на уровне SQL?
Допустим, я хотел иметь приложение, которое могло бы легко переключать БД на сервере. Я в основном думаю о SQL Server как об основной серверной части, но с возможностью перехода на другой движок БД. Firebird и PostGreSQL, кажется, имеют (из моей краткой экскурсии по википедии) наиболее распространенные с SQL Server (плюс они бесплатны).
Насколько похожи будут настройка БД, доступ, запросы и т. д. Для Firebird, PostGreSQL и MS SQL Server?
Ответы 4
К сожалению, SQL у разных поставщиков сильно различается. Практически невозможно написать все, кроме самого тривиального SQL для работы в ряде СУБД - и тогда вы окажетесь на территории с наименьшим общим знаменателем. Намного лучше использовать уровень абстракции для обработки хотя бы соединения с базой данных (включая доступ, отправку запросов) и либо ORM для обработки самого SQL, либо SQL для каждого поставщика.
Если вы хотите посмотреть, как они различаются - хорошими примерами являются автоматическое увеличение идентификаторов и получение идентификатора последней вставленной записи.
Я работал над одним проектом, где абсолютно необходимо было поддерживать множество баз данных, включая как минимум Access, SQL Server и Oracle.
Так что я знаю, что это можно сделать. В основном DML (SELECT, UPDATE, INSERT ...) - то же самое, и, конечно же, у нас не было серьезных проблем, заставляющих его работать во всех базах данных - просто случайные неприятности. В то время MySQL был исключением, так как он просто не обладал достаточными возможностями.
Мы обнаружили большинство различий в DDL, но с правильной архитектурой (которая у нас была) исправить это несложно.
Единственное, что вызывало у нас проблемы, это генерация уникальных идентификаторов - автоинкремент нестандартен. К счастью, в базе данных, содержащей около 40 таблиц, было лишь несколько мест, где требовались уникальные идентификаторы (хороший дизайн БД). В конце мы генерируем уникальный идентификатор в коде и обрабатываем любые конфликты (все в транзакциях).
Это действительно упростило задачу, потому что мы избегали использования автоинкремента для полей идентификатора, труднее придумать уникальные ключи - но в конечном итоге лучше.
Что ж, материалы CRUD должны быть одинаковыми везде, но если вы создаете что-то сложное, вы, вероятно, захотите использовать триггеры и хранимые процедуры, и в этом случае совместимость станет низкой. Написание приложения, не зависящего от СУБД, обычно означает перенос большей части бизнес-логики за пределы базы данных, поэтому наличие трехуровневого приложения, IMHO, в таком случае просто необходимо.
В качестве альтернативы вы можете использовать некоторую библиотеку-оболочку, которая работает как слой абстракции, но я еще не видел такой, которая могла бы правильно выполнять работу в диапазоне СУБД. Конечно, это также зависит от используемого вами языка программирования.
Как указано в других ответах, СУБД сильно различаются, если вы выйдете за рамки базового материала SELECT / INSERT (а иногда и там).
Мы также должны поддерживать совместимость с несколькими СУБД. На мой взгляд, обычно лучше всего использовать какой-то уровень совместимости. У нас есть собственная библиотека абстракции БД, но доступно несколько инструментов.
В частности, было бы неплохо взглянуть на популярные ORM (Hibernate, nHibernate и т. д.). Обычно они предлагают независимость от БД как своего рода побочный эффект. По крайней мере, в Hibernate есть специальный язык запросов, который автоматически переводится на SQL для СУБД, которую вы используете.