4. SQL/92 в сравнении с SQL/89

В этой части курса содержится краткая сводка основных различий между языками SQL/89 и SQL/92.

4.1. Сводка расширений SQL/92 по отношению к SQL/89

В этом разделе мы приводим сводку основных новых свойств, введенных в SQL/92.

1. Все, что относится к встроенному SQL. Встроенный SQL не являлся частью SQL/89 и был частично специфицирован только в приложениях. Кроме того, в этих приложениях не специфицировалась поддержка языков Си и Ада.
2. Все, что относится к работе с каталогами и почти все, что касается работы со схемами. В SQL/89 имелся оператор CREATESCHEMA, но не было оператора DROPSCHEMA, и все операторы CREATETABLE, CREATEVIEW и GRANT должны были специфицироваться как "элементы схемы" внутри такого оператора CREATESCHEMA (т.е. не было понятия независимого выполнения таких операторов, как в SQL/92). Однако понятие схемы было по существу не определено. Заметим также, что CREATETABLE, CREATEVIEW и GRANT в SQL/89 были только операциями определения данных; не существовали DROPTABLE, ALTERTABLE и т.д.
3. Возможность включать в модуль все виды операторов SQL. Как уже отмечалось, CREATETABLE, CREATEVIEW и GRANT в SQL/89 должны были выполняться как компоненты операции CREATESCHEMA; на самом деле, CREATESCHEMA, CREATETABLE, CREATEVIEW и GRANT вместе составляли отдельный "язык схемы", который отличался от "языка модулей". Нежелательное и не необходимое различие между языком схем и языком модулей почти полностью устранено в SQL/92.
4. Возможность включать все виды операций SQL (в частности, возможность смешивать операции определения данных и манипулирования данными) в одну транзакцию. По причине разделения языков схем и модулей, отмеченного в предыдущем параграфе, SQL/89 не обладал этим свойством.
5. Все, что относится к управлению подключениями и сессиями.
6. Оператор SETTRANSACTION, включающий, в частности, возможность определения уровня изоляции (в SQL/89 поддерживался только уровень SERIALIZABLE, и только неявно).
7. Все, что относится к работе с доменами, включая CREATE, ALTER и DROPDOMAIN.
8. Операторы ALTER и DROPTABLE.
9. Все, что связано с работой с временными таблицами.
10. Варианты CASCADED и LOCAL опции проверки при CREATEVIEW.
11. Оператор DROPVIEW.
12. Почти все, что относится к работе с ограничениями целостности, за исключением случаев определения возможного и внешнего ключей и одного простого вида проверочного ограничения базовой таблицы. В SQL/89 имелись возможные и внешние ключи и проверочные ограничения для одной строки (т.е. ограничения, которые можно проверять для данной строки, рассматривая ее в изоляции). Однако отсутствовали общие (с несколькими строками) ограничения, не было разновидностей FULL и PARTIAL для соответствия внешних ключей и не было отложенных проверок (DEFERRABLE, INITIALLYDEFERRED, SETCONSTRAINTS и т.д.).
13. Оператор REVOKE.
14. Строки символов переменной длины.
15. Битовые строки постоянной и переменной длины.
16. Все, что относится к работе с датами и временем.
17. Почти все, что касается работы с наборами символов, сравнениями, трансляциями и преобразованиями (включая поддержку национальных наборов символов и наборов символов для идентификаторов). В SQL/89 поддерживался тип данных строк постоянной длины вместе с соответствующим набором операторов присваивания и сравнения, но это все, что было (в частности, набор символов и правила их сравнения определялись по существу в реализации).
18. Все скалярные операторы и функции (за исключением +, -, *, / и USER), включающие, в частности, операторы CASE и CAST для управления преобразованиями типов данных.
19. Существенно улучшенная ортогональность в скалярных выражениях, включая, в частности, возможность использования скалярных выражений из базы данных как операндов внутри таких выражений.
20. Спецификации FORUPDATE, SCROLL и INSENSITIVE в DECLARECURSOR.
21. Существенно улучшенная ортогональность в табличных выражениях, включая
    (а) возможность вводить имена столбцов результата и имена таблиц;
    (b) набор правил вывода имени столбца;
    (c) возможность вложенных табличных выражений.
    
22. Явная поддержка INTERSECT, EXCEPT и JOIN (включая естественные и внешние соединения).
23. Конструкторы строк, включая, в частности, возможность использования таких конструкторов в условных выражениях наряду со скалярами.
24. Новые условия MATCH и UNIQUE.
25. Новые условия IS[NOT]TRUE, IS[NOT]FALSE и IS[NOT]UNKNOWN.
26. Все, что касается динамического SQL.
27. Информационная схема.
28. SQLSTATE и все, что касается работы с областью диагностики.
29. Более исчерпывающее обращение с прямым SQL (хотя многие конкретные вещи все еще остались определяемыми в реализации).

4.2. Несовместимости SQL/92 и SQL/89

Документ 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 это имя схемы, которое, в свою очередь, включает (возможно, неявное) имя каталога как другой (более высокого уровня) квалификатор.

4.3. Осуждаемые свойства языка SQL/89

В стандарте SQL/92 присутствует приложение, устанавливающее "осуждаемые свойства" языка, т.е. свойства, которые оставлены в SQL/92 только для обеспечения совместимости с SQL/89 и которые, вероятно, будут удалены в какой-нибудь будущей версии стандарта. Эти свойства включают следующее:

1. Переменная SQLCODE (предпочтительнее SQLSTATE). Следовательно, например, целая переменная программы на языке Кобол, определенная как USAGEASCOMPUTATIONAL, также является осуждаемой, поскольку USAGE поддерживается только для SQLCODE.
2. Беззнаковые целые как элементы упорядочивания в разделе ORDERBY (предпочтительнее использовать имена столбцов, введенные через раздел AS для соответствующих элементов выборки).
3. Незаключенный в скобки список параметров в процедурах (предпочтительнее заключенные в скобки списки через запятую).

Назад | Содержание | Вперед