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

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

Это разновидность «скрытной блокировки». Джоэл подробно рассказывает здесь:

• http://www.joelonsoftware.com/articles/fog0000000056.html
• http://www.joelonsoftware.com/articles/fog0000000052.html

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

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

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

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

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

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

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

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

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

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