Введение в стандарты языка баз данных SQL

       

Несовместимости SQL/ и SQL/


Документ SQL/92 включает приложение, в котором устанавливаются несовместимости между SQL/92 и SQL/89. Мы перечислим эти несовместимости ниже.

  1. В SQL/92 имеется более 100 дополнительных зарезервированных слов. Конкретные детали следует смотреть в самом стандарте.
  2. В SQL/89 модуль, происходящий из встроенного SQL, имел идентификатор авторизации, определяемый в реализации; в SQL/92 он вообще не имеет идентификатора авторизации.
  3. Имена параметров в SQL/89 не имели префикса в виде двоеточия. SQL/92 требует наличия такого префикса.
  4. SQL/89 допускает определение двух различных возможных ключей для одной базовой таблицы с заданием одного и того же набора столбцов. SQL/92 этого не допускает.
  5. SQL/89 не препятствует рекурсивному определению представления, т.е. в терминах его же самого. SQL/92 не допускает этой возможности.
  6. Семантика WITHCHECKOPTION была двусмысленной в SQL/89, но была прояснена в SQL/92. (По крайней мере, это утверждается в документе SQL/92. Более точно, опция проверки не являлась наследуемой в SQL/89, но является таковой в SQL/92 по умолчанию.)
  7. Пусть в спецификации курсора C отсутствует раздел GROUPBY, и пусть курсор C открывается несколько раз внутри одной и той же транзакции. В SQL/89 требуется, чтобы строки, доступные через курсор C, возвращались в одном и том же порядке при каждом открытии. В SQL/92 порядок при каждом открытии зависит от реализации и, следовательно, может отличаться для разных открытий курсора.
  8. В соответствии со стандартом SQL/89, если курсор установлен на некоторую строку или перед ней, и эта строка удаляется, курсор устанавливается перед следующей строкой или (если следующей строки нет) после последней строки. (Заметим, что это требование достаточно трудно удовлетворить в реализации.) В SQL/92 изменение состояния курсора определяется только если операция DELETE производится через тот же самый курсор; в противном случае воздействие на курсор зависит от реализации.
  9. В SQL/89 привилегия SELECT требовалась только для таблиц, к которым производится доступ через операторы FETCH или одиночный SELECT. В SQL/92 это дополнительно требуется для таблиц, упоминаемых в некоторых табличных выражениях, условных выражениях и скалярных выражениях.


В стандарте SQL/ 92 указываются еще некоторые виды несовместимости, но их формулировка слишком сложна, а сами они не слишком важны, чтобы упоминать о них в нашем курсе. С другой стороны, независимые авторы (в частности, К.Дейт) отмечают наличие некоторых дополнительных несовместимостей, не специфицированных в стандарте. Среди них следующие:


  1. Фактически, SQL/89 состоял из двух разных языков - языка модулей и языка определения схем. Операторы CREATETABLE, CREATEVIEW и GRANT могли появляться только как элементы внутри оператора CREATESCHEMA, и этот оператор в свою очередь был оператором языка определения схем; таким образом, CREATESCHEMA (и следовательно, CREATETABLE, CREATEVIEW и GRANT) не могли появляться внутри модуля. В попытке сохранить совместимость с этим достаточно странным обстоятельством, в стандарте SQL/92 многократно указывается, что оператор CREATESCHEMA мог бы не включаться в модуль; однако из описания языка не видно способа осуществить эту возможность.
  2. В SQL/89 привилегия REFERENCES требовалась только для возможных ключей, на которые ссылались некоторые внешние ключи. В SQL/92 это требуется для любого столбца, который встречается в некотором ограничении целостности.
  3. Стандарт SQL/89 допускает использование квалифицированных имен столбцов в разделе ORDERBY. SQL/92 этого не допускает. (На самом деле, это изменение лучше расценивать как исправление ошибки SQL/89, а не как несовместимость, поскольку в соответствии со спецификациями SQL/89 область видимости квалифицированного имени столбца не включала или, по крайней мере, не должна была включать раздел ORDERBY.)
  4. В соответствии со стандартом SQL/92 значением константы USER является текущий идентификатор авторизации. В SQL/89 значением USER должен являться идентификатор авторизации модуля.
  5. В SQL/89 квалификатором имени высшего уровня для (например) имен базовых таблиц был идентификатор авторизации. В SQL/92 это имя схемы, которое, в свою очередь, включает (возможно, неявное) имя каталога как другой (более высокого уровня) квалификатор.



Содержание раздела