DELETE emp WHERE empno = 111; SELECT * FROM emp;

/* мы должны получить тот же результат */ ROLLBACK;

Мы победили мутирующую таблицу! Теперь у нас есть всеобъемлющее рещение, позволяющее обойти эту проблему. Наш пример относится к операции DELETE, но мы можем, конечно, распространить продемонстрированный в нем метод и на операцию UPDATE. Этот метод дает надежное и эффективное рещение проблемы мутирующих таблиц, не оказывая при этом существенного влияния на производительность.

К сведению

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

При обработке оператора делается ссылка из подчиненной таблицы на главную, позволяющая соблюсти ограничение ссылочной целостности, и теперь SQL-оператор в триггере пытается модифицировать главную таблицу. Решение этой проблемы такое же, как проблемы мутирующих таблиц. Сохраните в глобальных переменных PL/SQL необходимые изменения, а затем внесите их при помощи триггера AFTER уровня оператора.

Peiq/рсивный SQL

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

В Oracle? есть три соверщенно разных типа рекурсивного SQL:

SQL-операторы традиционного типа, которые Oracle выдает для собственных управленческих целей, они всегда разбираются как принадлежащие пользователю SYS;

пользовательский SQL, выполняемый из PL/SQL;

SQL, который Oracle генерирует для поддержки декларативных ограничений. Этот тип встречается на удивление редко, так как для реализации таких ограничений в больщинстве случаев производятся прямые вызовы требуемых функций внутри сервера. Исключение - ON DELETE CASCADE.

Проблема тысячелетия: перспектива для Oracle

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

Предыстория

Что такое проблема тысячелетия? Когда проектировались и писались старые системы, никто не побеспокоился о том, чтобы для представления года использовалось минимум три (а лучще четыре) значащие цифры. Чтобы проиллюстрировать этот вопрос, давайте рассмотрим, как чаще всего представляют дату. Обьгано мы нищем дату в таком виде: 01/01/98, 01 JAN 98, 1st January 98 и т.п. Будем ли мы писать дату как 01/01/00 или 01/01/000, когда наступит 2000-й год? Может быть, но выглядеть это будет странно, поэтому, скорее всего, мы будем писать дату как 01/01/2000. Во многих компьютерных системах в полях даты на экранах век не отображается, хуже того, они не позволяют вводить век при вводе дат. К тому же, как правило, в них подразумевается, что все даты относятся к двадцатому веку, и когда пользователь вводит 01/01/98, система неявно считает, что он имеет в виду 01/01/1998. Чтобы довести наши рассуждения до логического конца, скажем, что когда пользователь вводит 01/01/00, система считает, что он имеет в виду 01/01/1900 - а как раз это он (почти во всех случаях) и не имеет в виду. Вот в чем суть проблемы.

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

Ранее мы описали проблемы, которые могут возникнуть в прикладном ПО. Кроме них, несомненно, будут и проблемы с аппаратными средствами, операционными системами и системным ПО (включая большинство систем управления базами данных).

У всех компьютеров есть внутренние часы, выдающие текущую дату и время. Эти данные хранятся в аппаратных средствах обычно во внутреннем формате. В более старых машинах, страдающих от дефицита оперативной

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

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

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

Каковы последствия для пользователей таких систем, сидящих на этих бомбах замедленного действия? Они могут быть катастрофическими и очень дорогостоящими! Давайте рассмотрим в качестве простого примера систему начисления оплаты за время работы консультантов. В конце периода система определяет, сколько дней провел консультант у клиента, и умножает это число на дневную ставку. Предположим, что консультант Смит работал у клиента Джонс Индастриз с 29 декабря 1999 г. по 2 февраля 2000 г. Система начисления оплаты неверно истолковывает вторую дату, введенную как 02-02-00, и считает, что это 2 февраля 1900 г. В процессе расчета она вычитает первую дату из второй, получает большое отрицательное число и умножает его на ставку консультанта. В итоге выходит еще большее отрицательное число.

В результате вместо отправки скромного счета за работу консультанта (консультанты никогда не посылают маленькие счета) мы шлем запрос на большой кредит, которого, без сомнения, заслуживает наша маленькая консультационная фирма. Вы считаете этот пример надуманным? Может быть, но он ясно показывает, какие неприятности могут произойти.

Теперь, когда понятно, какие проблемы могут возникнуть, если проблемой тысячелетия не заниматься, рассмотрим последствия для систем, в которых используется база данных Oracle. Как мы говорили в главе 7, в Oracle есть тип данных DATE, предназначенный для хранения даты и времени, причем время в этом случае хранится с точностью до секунды. Этот тип поддерживает даты в диапазоне с 1 января 4712 г. до н.э. до 31 декабря 4712 г. н.э. Во внутренних структурах Oracle хранит дату в упакованном формате как семибайтное целое, где на век, год, месяц, день, час, минуту и секунду выделяется по одному байту. Имея этот внутренний формат, Oracle неявно записывает век во всех датах, хранящихся в столбцах типа DATE.