Причины различий в SQL

https://stackoverflow.com/questions/37441

09-06-2019
|

Вопрос

Почему дистрибутивы SQL настолько нестандартны, несмотря на существующий стандарт ANSI для SQL?Действительно ли существует так много значимых различий в том, как работают базы данных SQL, или это только две базы данных, с которыми я работал:MS-SQL и PostgreSQL?Почему возникают эти различия?

Решение

Это форма "Скрытой блокировки".Джоэл вдается здесь в мельчайшие подробности:

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

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

Другие советы

Стандарт ANSI определяет только ограниченный набор команд и типов данных. Как только вы выйдете за их пределы, разработчики сами по себе. А некоторые очень важные понятия вообще не указаны, например, автоинкрементные столбцы. SQLite просто выбирает первое ненулевое целое число, MySQL требует AUTO INCREMENT , PostgreSQL использует последовательности и т. Д. Это беспорядок, и это только среди баз данных OSS! Попробуйте заставить Oracle, Microsoft и IBM совместно решить сложную задачу.

Во-первых, я не нахожу базы данных, скажем, браузерами или операционными системами с точки зрения несовместимости. Любой, у кого есть несколько часов обучения, может начать делать выборки, вставки, удаления и обновления в любой базе данных SQL. Между тем, сложно писать HTML, который одинаково визуализируется в каждом браузере, или писать системный код для более чем одной ОС. Как правило, различия в SQL связаны с производительностью или довольно эзотерическими функциями. Как представляется, основным исключением являются форматы и функции даты.

Во-вторых, разработчики баз данных, как правило, заинтересованы в добавлении функций, которые отличают их продукт от всех остальных. Такие продукты, как Oracle, MS SQL Server и MySQL, представляют собой обширные экосистемы, которые на практике редко подвергаются перекрестному опылению. На моем рабочем месте мы используем Oracle и MySQL, но, возможно, мы могли бы перейти на 100% Oracle примерно за день, если это необходимо или желательно. Поэтому меня очень волнуют блестящие игрушки, которые Oracle дает нам с каждым выпуском, но я даже не знаю, какую версию MySQL мы используем. IBM, Microsoft, PostgreSQL и другие могут не существовать для нас. Наличие функций для получения и удержания клиентов и пользователей гораздо важнее, чем совместимость в мире баз данных. (Полагаю, это положительный ответ на ответ «заблокирован»).

В-третьих, существуют разные причины, по которым разные компании используют SQL по-разному. Например, Oracle имеет систему с несколькими версиями, которая позволяет очень быстрое и масштабируемое согласованное чтение. В других базах данных такой возможности нет, но обычно они быстрее вставляют строки и откатывают транзакции. Это принципиальная разница в этих системах. Это не делает одно лучше другого (по крайней мере, в общем случае), просто отличается. Не следует удивляться, если SQL-компонент ядра базы данных использует свои преимущества и пытается минимизировать его недостатки. На самом деле, разработчики не будут безответственно не делать этого.

Джон: Стандарт на самом деле охватывает множество предметов, в том числе столбцы идентификаторов, последовательности, триггеры, подпрограммы, upsert и т. д. Но, конечно, многие из этих компонентов стандартов могли быть внедрены позже, чем первые реализации; и это может быть причиной того, что соответствие стандартам SQL в целом несколько ниже.

Neall: на самом деле есть области, где стандарт SQL опережает реализации. Например, было бы неплохо иметь CREATE ASSERTION, но, насколько мне известно, ни одна СУБД еще не реализует утверждения.

Лично я считаю, что закрытая природа некоторых стандартов ISO (например, стандарта SQL) является частью проблемы: когда стандарт недоступен онлайн, он менее известен для разработчиков / планировщиков, и слишком мало клиенты просят о соответствии, потому что они не знают, о чем просить.

Это, безусловно, эффективная блокировка, как говорит 1800 год. Но по справедливости для поставщиков баз данных стандарт SQL всегда играет в догонялки к текущим наборам функций баз данных. Большинство баз данных, которые мы имеем сегодня, имеют довольно древние линии. Если вы проследите Microsoft SQL Server до его корней, я думаю, вы найдете Ingres - одну из самых первых реляционных баз данных, написанную в 70-х годах. И Postgres был первоначально написан некоторыми из тех же людей в 80-х годах как преемник Ingres. Oracle возвращается очень далеко, и я не уверен, откуда появился MySQL.

Непереносимость базы данных - отстой, но это может быть намного хуже.

Лицензировано под: CC-BY-SA с атрибуция

Не связан с StackOverflow