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

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

Недостатки статического SQL

Как следует из названия статический SQL , профамма, созданная по методике, описанной в главе 17 (базовые переменные, наборы записей, инструкции declare cursor, open, fetch и close), имеет заранее определенную, жестко фиксированную схему доступа к базе данных. В каждой встроенной инсфукции SQL профаммист заранее указывает, на какие таблицы и столбцы он будет ссылаться. Входные базовые переменные придают статическому SQL некоторую гибкость, но не могут коренным образом изменить его статическую природу Вспомним, что базовую переменную разрешается применять в инструкции SQL везде, где может стоять константа. С помощью базовой переменной можно изменить условие отбора

exec sql select name, quota, sales from salesreps where quota > :cutoff amojnt;

С помощью базовых переменных можно изменять добавляемые или обновляемые данные:

exec sql update salesreps

set quota = quota + :increase where quota > :cutoff amount;

Однако базовую переменную нельзя использовать вместо имени таблицы или столбца. Приведенные ниже примеры упофебления базовых переменных which ta-Ые и which column являются неправильными:

exec sql update :which table

set :which column = 0;

exec sql declare cursor cursor? for select *

from :which table;

Даже если бы вы могли использовать базовую переменную таким образом (а этого делать нельзя), немедленно возникла бы другая проблема. Количество столбцов, извлеченных второй инструкцией, будет изменяться в зависимости от того, какая таблица была задана в базовой переменной. Если задана таблица OFFICES, то результаты запроса будут иметь шесть столбцов, если таблица SALESREPS, то - девять столбцов Более того, типы данных столбцов у двух указанных таблиц различны. Но чтобы написать инструкцию FETCH для какого-либо запроса, необходимо заранее знать, сколько будет столбцов в таблице результатов запроса и каковы их типы данных, так как для каждого столбца необходимо указать базовую переменную, в которую будет передаваться содержимое столбца:

exec sql fetch cursor?

into :varl, :var2, :var3;

Таким образом, мы приходим к выводу: если профамма только на этапе выполнения может решить, какие инсфукции SQL применять и на какие таблицы и столбцы ссылаться, то статический SQL для нее непригоден. Описанная проблема решается с помошью динамического SQL, который свободен от указанных ограничений.

В реляционных СУБД компании IBM динамический SQL использовался с самого начала Он много лет применялся также в СУБД для мини-компьютеров и системы UNIX Однако динамический SQL не упоминается в стандарте SQL1, в нем описывается только статический SQL По иронии судьбы, отсутствие динамического SQL в стандарте SQL1 объяснялось тем, что стандарт должен позволять создавать клиентские профаммы для работы с базами данных, переносимые между СУБД различных типов На самом деле все наоборот: переносимые клиентские профаммы следует создавать именно с использованием динамического SQL.

В такой ситуации стандартом де-факто стал динамический SQL, применявшийся в DB2 Динамический SQL, поддерживавшийся другими СУБД компании IBM того времени (SQL/DS и OS/2 ЕЕ), был почти идентичен тому, который использовался в DB2. Большинство других реляционных СУБД также последовали стандарту DB2. В 1992 году динамический SQL получил официальную поддержку со стороны стандарта SQL2, разработчики которого в основном придерживались методики компании IBM. На нижнем уровне (Entry Level) совместимости со стандартом SQL2 поддержка динамического SQL не фебуется, но она обязательна для тех СУБД, которые претендуют на совместимость с SQL2 на уровне Intermediate Level или Full Level.

Основные концепции динамического SQL

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

Чтобы понять, как работает динамический SQL, и сравнить его со статическим SQL, полезно еще раз рассмотреть процесс вьшолнения инструкции SQL в СУБД, впервые представленный на рис. 17.1 и повторно приведенный на рис. 18.1. Вспомним (см. главу 17), что для статической инструкции SQL первые четыре действия выполняются на этапе компиляции. В процессе компиляции профаммы утилита BIND (или ее эквивалент) сохраняет в базе данных план выполнения инсфукции А во время выполнения профаммы СУБД просто реализует план для данной инструкции.

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

Инструкция SQL

С Синтаксический N Ч анализ инструкции J

/~1Троверка1тарамётров V инструкции J

Оптимизация инструкции

( Генерация плана V выполнения У

План

Двоичная форма инструкции SQL

Исполнение плана

Статический SQL

Препроцессор

Утилита BIND

Динамический SQL -----

Инструкция PREPARE

Инструкция EXECUTE IMMEDIATE

г1СТруК1

;хЕси

4: ♦

Инструкция EXECUTE

Рис 18; 1. Процесс выполнения инаруюи SQL в

Как и следовало ожидать, динамический SQL менее эффективен (в смысле производительности), чем статический SQL. По этой причине всегда, когда это возможно, используется статический SQL, и большинству прикладных профаммистов раньше никогда не приходилось иметь дело с динамическим SQL. Однако в связи с тем, что для работы с базами данных в настоящее время широко применяется архитектура