Реальная эффективность этого метода зависит от того, компенсирует ли выигрыш, достигнутый благодаря работе в рамках серверного процесса Oracle и устранению переключений контекста, потерю эффективности из-за перехода на Java. Как известно, сегодня очень немногие из нескольких миллиардов строк унаследованного кода на нашей планете написаны на Java, поэтому если вы надеетесь воспользоваться преимуществом обращений к SGL-программам с целью применения существующих сервисных программ, то не ждите особой пользы от поддержки Java, которая должна появиться в версии 8.1.
Отложенная проверка ограничений
В книге "Oracle: проектирование баз данных" ER-моделированию мы посвятили целую главу. Были исследованы возможности реализации в Oracle различных конструкций, которые могут встречаться в модели. Наш принцип всегда состоял в том, чтобы вводить ограничения и условия, вытекающие из модели, на сервере и везде, где это возможно, использовать средства Oracle, например ограничения (constraints). Однако, что нам доставляло определенные неудобства, так это связи, которые являются обязательными на обоих концах. Давайте рассмотрим пример, показанный на рис. 3.3.
Заказ   |	Строка заказа
—————————— |;	————————————————————————
'А—\- Состоит из ————Входит в——«;
Рис. 3.3. Связь, являющаяся обязательной на обоих концах
В этой модели мы констатируем, что не можем иметь строку заказа при отсутствии соответствующего заказа (что совершенно справедливо), а также не допускаем наличия заказов, не имеющих строк. Проблема заключается в том, что мы должны временно нарушить одно из этих правил, так как у нас нет возможности создать заказ и его первую строку одновременно. В принципе, можно не обращать внимания на это временное нарушение, если к моменту фиксации транзакции оно будет устранено.
Чтобы ввести правило, согласно которому строка заказа должна входить в заказ, мы можем определить ограничение внешнего ключа для таблицы Order_Lines и сделать столбцы внешнего ключа ненулевыми (NOT NULL). Чтобы ввести утверждение, в соответствии с которым в заказе должна быть хотя бы одна строка, можно написать триггер уровня строки для таблицы Orders, запускающийся при вставке, обновлении, удалении и проверке строк заказов. Теперь мы имеем классический сценарий о курице и яйце. Если попытаться сначала создать заказ, наш триггер не даст выполнить транзакцию, а если попробовать начать со строки заказа, то ничего не получится из-за ограничения.
3. Некоторые усовершенствования в Oracle 8	39