Oracle для профессионалов
       

Влияние стандартов


Если все СУБД соответствуют стандарту SQL92, они должны быть одинаковы. Так считают многие. Сейчас я развею этот миф.

SQL92 — это стандарт ANSI/ISO для СУБД. Он является развитием стандарта ANSI/ISO SQL89. Этот стандарт задает язык (SQL) и поведение (транзакции, уровни изоляции и т.д.) для СУБД. Знаете ли вы, что многие коммерческие СУБД соответствуют стандарту SQL92? А знаете ли, как немного это значит для переносимости запросов и приложений?

Начиная читать стандарт SQL92, обнаруживаешь, что он имеет четыре уровня.

  • Начальный уровень. Именно этому уровню соответствует большинство предлагаемых СУБД. Этот уровень является незначительным развитием предыдущего стандарта, SQL89. Ни одна СУБД не сертифицирована по более высокому уровню. Более того, фактически Национальный институт стандартов и технологий (National Institute of Standards and Technology — NIST), агентство, сертифицировавшее соответствие стандартам SQL, сертификацией больше не занимается. Я входил в состав команды, сертифицировавшей Oracle 7.0 в NIST как соответствующий начальному уровню стандарта SQL92 в 1993 году. СУБД, соответствующая начальному уровню этого стандарта, поддерживает набор возможностей Oracle 7.0.

  • Переходный. С точки зрения поддерживаемых возможностей это что-то среднее между начальным и промежуточным уровнем.

  • Промежуточный. Этот уровень добавляет много возможностей, в том числе (этот список далеко не исчерпывающий):

    • динамический SQL;

    • каскадное удаление для обеспечения целостности ссылок;

    • типы данных DATE и TIME;

    • домены;

    • символьные строки переменной длины;

    • выражения CASE;

    • функции CAST для преобразования типов данных.

    • Полный. Добавляет следующие возможности (этот список тоже не исчерпывающий):

    • управление подключением;

    • тип данных BIT для битовых строк;



    • отложенная проверка ограничений целостности;

    • производные таблицы в конструкции FROM;

    • подзапросы в конструкции CHECK;

    • временные таблицы.

      • В стандарт начального уровня не входят такие конструкции, как внешние соединения, новый синтаксис для внутренних соединений и т.д. Переходный уровень требует поддержки соответствующего синтаксиса внешнего и внутреннего соединения. Промежуточный уровень добавляет новые возможности, а полный и представляет собой, собственно, SQL92. В большинстве книг по SQL92 не различаются эти уровни поддержки, что сбивает с толку. В них демонстрируется, как должна работать "идеальная" СУБД, полностью реализующая стандарт SQL92. В результате нельзя взять книгу по SQL92 и применить представленные в ней приемы к СУБД, соответствующей стандарту SQL92. Например, в СУБД SQL Server предлагаемый стандартом синтаксис "внутреннего соединения" в SQL-операторах поддерживается, а в СУБД Oracle — нет. Но обе эти СУБД соответствуют стандарту SQL92. В СУБД Oracle можно выполнять внешние и внутренние соединения, но делать это надо не так, как в SQL Server. В результате начальный уровень стандарта SQL92 мало что дает, а при использовании средств более высоких уровней возможны проблемы при переносе на другую СУБД.


      Не надо бояться использовать специфические средства конкретной СУБД, — за них заплачено немало денег. В каждой СУБД есть свой набор уникальных возможностей, и в любой СУБД можно найти способ выполнить необходимое действие. Используйте в текущей СУБД лучшее и реализуйте новые компоненты при переходе на другие СУБД. Используйте соответствующие приемы программирования, максимально изолирующие остальную часть приложения от этих изменений. Эти же приемы программирования применяются разработчиками переносимых приложений, поддерживающих несколько ОС. Цель в том, чтобы в полной мере использовать имеющиеся средства, но при этом иметь возможность менять реализацию в каждом конкретном случае.

      Например, типичная функция многих приложений баз данных — генерация уникального ключа для каждой строки. При вставке строки система должна автоматически сгенерировать ключ. В Oracle для этого предлагается объект базы данных — последовательность (SEQUENCE). В Informix имеется тип данных SERIAL. Sybase и SQL Server поддерживают тип данных IDENTITY. В каждой СУБД имеется способ решить эту задачу. Однако методы решения различны, различны и возможные последствия их применения. Поэтому знающий разработчик может выбрать один из двух вариантов:

    • разработать метод генерации уникального ключа, полностью независимый от СУБД;


    • согласиться с разными реализациями и использовать разные методы генерации ключей в зависимости от СУБД.


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

      create table id_table (id_name varchar(30), id_value number); insert into id_table values ('MY_KEY', 0);

      Затем для получения нового ключа необходимо выполнить следующий код:

      update id_table set id_value = id_value + 1 where id_name = 'MY_KEY'; select id_value from id_table where id_name = 'MY_KEY';



      Выглядит он весьма просто, но выполнять подобную транзакцию в каждый момент времени может только один пользователь. Необходимо изменить соответствующую строку, чтобы увеличить значение счетчика, а это приведет к поочередному выполнению операций. Не более одного сеанса в каждый момент времени будет генерировать новое значение ключа. Проблема осложняется тем, что реальные транзакции намного больше транзакции, показанной выше. Показанные в примере операторы UPDATE и SELECT — лишь два из множества операторов, входящих в транзакцию. Необходимо еще вставить в таблицу строку с только что сгенерированным ключом и выполнить необходимые действия для завершения транзакции. Это упорядочение доступа будет огромным ограничивающим фактором для масштабирования. Подумайте о последствиях, если этот метод применить для генерации номеров заказов в приложении для обработки заказов на Web-сайте. Одновременная работа нескольких пользователей станет невозможной, — заказы будут обрабатываться последовательно.

      Правильное решение этой проблемы состоит в использовании для каждой СУБД соответствующего кода. В Oracle (предполагается, что уникальный ключ необходимо генерировать для таблицы T) лучшим способом будет:

      create table t ( pk number primary key, ... ); create sequence t_seq; create trigger t_trigger before insert on t for each row begin select t_seq.nextval into :new.pk from dual; end;

      В результате каждая вставляемая строка автоматически и незаметно для приложения получит уникальный ключ. Тот же эффект можно получить и в других СУБД с помощью их типов данных — синтаксис оператора создания таблицы изменится, а результат будет тем же. Мы использовали второй вариант — специфические средства каждой СУБД для неблокируемой, высокопараллельной генерации уникального ключа, что, однако, не потребовало реальных изменений в коде приложения — все необходимые действия выполнены операторами DDL.

      Приведу еще один пример безопасного программирования, обеспечивающего переносимость. Если понятно, что каждая СУБД реализует одни и те же возможности по-разному, можно при необходимости создать дополнительный уровень доступа к базе данных. Предположим, вы программируете с использованием интерфейса JDBC. Если используются только простые операторы SQL, SELECT, INSERT, UPDATE и DELETE, дополнительный уровень абстракции скорее всего не нужен. Можно включать код SQL непосредственно в приложение, если использовать конструкции, поддерживаемые во всех СУБД, с которыми должно работать приложение. Другой подход, одновременно упрощающий перенос и повышающий производительность, состоит в использовании хранимых процедур, возвращающих результирующие множества. Если разобраться, окажется, что все СУБД могут возвращать результирующие множества из хранимых процедур, но способы при этом используются абсолютно разные. Для каждой СУБД придется написать свой исходный код.



      Теперь появляется выбор — либо не использовать хранимые процедуры, возвращающие результирующие множества, либо писать отдельный исходный код для каждой СУБД. Я, несомненно, выбрал бы метод "отдельный код для каждой СУБД" и активно использовал бы хранимые процедуры. Казалось бы, что при этом для перехода на другую СУБД потребуется больше времени. Однако оказывается, что этот подход упрощает создание приложений, переносимых на различные СУБД. Вместо поисков идеального кода SQL, работающего во всех СУБД (причем, как правило, в одних лучше, а в других — хуже), используется код SQL, максимально эффективный в конкретной СУБД. Его можно вынести из приложения, что дает дополнительные возможности настройки. Можно исправить запрос с низкой производительностью непосредственно в СУБД, и это изменение будет немедленно учтено, без исправлений в приложении. Кроме того, при использовании этого метода можно свободно и в полном объеме использовать преимущества предлагаемых производителем СУБД расширений языка SQL. Например, СУБД Oracle поддерживает иерархические запросы с помощью конструкции CONNECT BY

      в операторах SQL. Эта уникальная возможность очень поможет при создании рекурсивных запросов. В Oracle вы свободно сможете использовать это расширение SQL, поскольку оно — "вне" приложения (скрыто в базе данных). В других СУБД для достижения аналогичных результатов, возможно, придется использовать временные таблицы и хранимые процедуры. Вы заплатили за эти возможности, так почему же их не использовать.

      Такие же методы используют разработчики, создавая код, предназначенный для работы на множестве платформ. Корпорация Oracle, например, применяет описанную выше методику при разработке СУБД. Есть большой фрагмент кода (составляющий, однако, небольшую часть всего кода СУБД), который называется OSD-код (Operating System Dependent) и создается отдельно для каждой платформы. С помощью этого уровня абстракции в СУБД Oracle можно использовать специфические возможности ОС для обеспечения высокой производительности и интегрирования, не переписывая при этом код самой СУБД. Именно благодаря этому СУБД Oracle может работать как многопотоковое приложение в Windows и как многопроцессное — в UNIX. Механизмы межпроцессного взаимодействия абстрагированы до такого уровня, что могут воплощаться по-разному для каждой ОС; при этом обеспечивается такая же производительность, как и в приложениях, написанных специально для данной платформы.



      Помимо синтаксических различий в языке SQL, различаются реализации операторов, различной будет и производительность выполнения одного и того же запроса, есть проблемы управления одновременным доступом, уровней изолированности транзакций, согласованности запросов и т.д. Все это более детально будет рассмотрено в главах 3 и 4, — мы увидим, как сказываются эти различия. В стандарте SQL92 попытались дать четкие определения того, как должна выполняться транзакция, как должны обеспечиваться уровни изоляции, но в конечном итоге в разных СУБД результаты получаются различными. Все это связано с реализацией. В одной СУБД приложение будет вызывать взаимные блокировки и заблокирует все, что можно. В другой СУБД это же приложение не вызывает никаких проблем и работает отлично. В одной СУБД блокирование (физически упорядочивающее обращения) намеренно использовалось в приложении, а при его переносе в другую СУБД, где блокирования нет, получается неверный ответ. Чтобы перенести готовое приложение в другую СУБД, требуется много труда и усилий, даже если при первоначальной разработке неукоснительно соблюдался стандарт.


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