Мы создали индекс по функции: create index t idx on t(nvl(x,-l)) ;

С минимальными изменениями мы добились того же результата. Отсюда можно сделать следующие важные выводы.

СУБД - различны. Опыт работы с одной может оказаться полезен в другой, но

нужно быть готовым к ряду принципиальн1х отличий и многим очень мелким.

Мелкие различия (вроде обработки NULL-значений) могут иметь такое же влияние, как и принципиальные (например, механизм управления одновременным доступом).

Единственный способ справиться с этими проблемами - знать особенности работы СУБД и уметь реализовать предоставляемые ею возможности.

Разработчики часто спрашивают меня, как сделать в СУБД что-то конкретное. Например, меня спрашивают: Как создать временную таблицу в хранимой процедуре? . На такие вопросы я не даю прямого ответа - я всегда отвечаю вопросом: А для чего вам это нужно? . Неоднократно в ответ я слышал: Мы создавали временные таблицы в хранимых процедурах в SQL Server, и теперь нам надо это сделать в Oracle . Именно это я и предполагал услышать. В таком случае мой ответ прост: Вы ошибаетесь, думая, что надо создавать временные таблицы в хранимой процедуре в Oracle . На самом деле в СУБД Oracle это будет крайне неудачным решением. При создании таблиц в хранимых процедурах в Oracle вскоре обнаружится, что:

выполнение операторов ЯОД в этом контексте снижает масштабируемость;

постоянное выполнение операторов ЯОД снижает производительность;

выполнение операторов ЯОД приводит к фиксации транзакции;

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

динамический SQL в PL/SQL оптимизируется хуже и работает медленнее стати-

ческого.

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

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

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

SQL92 - это стандарт ANSI/ISO для СУБД. Он является развитием стандарта ANSI/ ISO SQL89. Этот стандарт задает язык (SQL) и поведение (транзакции, уровни изоли-

рованности и т.д.) для СУБД. Знаете ли вы, что многие коммерческие СУБД соответствуют стандарту SQL92? А знаете ли, как немного это значит для переносимости запросов и приложений?

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

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

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

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

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

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

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

домены;

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

выражения CASE;

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

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

управление подключением; тип данных 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, О) ;

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

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;

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