Oracle для профессионалов Том Кайт торгово-издательский дом DiaSoft

 CAST
для преобразования типов данных.
•
 Полный.
Добавляет следующие возможности (этот список тоже не исчерпываю-
щий):
управление подключением;
тип данных
 BIT
для битовых строк;
отложенная проверка ограничений целостности;
производные таблицы в конструкции
 FROM;
подзапросы в конструкции
 CHECK;
временные таблицы.
В стандарт начального уровня не входят такие конструкции, как внешние соедине-
ния, новый синтаксис для внутренних соединений и т.д. Переходный уровень требует
поддержки соответствующего синтаксиса внешнего и внутреннего соединения. Проме-
жуточный уровень добавляет новые возможности, а полный и представляет собой, соб-
ственно, SQL92. В большинстве книг по SQL92 не различаются эти уровни поддержки,
что сбивает с толку. В них демонстрируется, как должна работать "идеальная" СУБД,
63

---

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