Когда появилась OracleS, многие проектировщики и разработчики надеялись, что эта СУБД будет поддерживать триггеры SELECT. Такие триггеры позволили бы перехватывать запросы и выполнять определенные пользователем логические операции в момент запроса, что позволило бы упростить запрос. Триггеры SELECT также могли бы стать мощным средством реализации аудита и защиты данных, но, как ни привлекательны их возможности, в них нет того, что есть в триггерах INSTEAD OF.
В OracleS имеется нечто новое для мира триггеров — триггеры INSTEAD OF, которые определяются для представления, а не для таблицы. С помощью таких триггеров можно обойти ограничения, установленные Oracle на все представления, считающиеся необновляемыми. До версии 7.3 не было возможности выдавать предложения на языке DML (Data Manipulation Language — язык манипулирования данными) — INSERT, DELETE и UPDATE — для представления, которое содержало соединение. В версии 7.3 появилась возможность выдавать DML-предложения для представления, содержащего соединение, но с очень строгими ограничениями. В одном предложении можно обновлять только столбцы, принадлежащие одной таблице, причем это представление должно быть защищено по ключу, т.е. столбец (столбцы), по которому выполняется соединение, обновлять нельзя.
В OracleS триггеры INSTEAD OF определяются для тех же событий, что и их табличные аналоги INSERT, DELETE и UPDATE. Триггер, выполняющийся в момент блокировки, не предусмотрен, поэтому либо блокировка должна быть неявной, либо приложение должно знать, какие объекты блокировать (или для каких таблиц выполнять SELECT...FOR UPDATE). Несмотря на это незначительное неудобство, новые триггеры позволили устранить существенное для разработчиков ограничение. Разработчик теперь имеет возможность задавать логику выполнения DML-предложений в любом определении представления, и эту логику требуется реализовать всего один раз (в триггерах). Без таких триггеров у разработчиков было два возможных решения:
•    помещать логику обновления представления в хранимую процедуру, которую должно вызывать каждое приложение, использующее триггер;
•    включать в каждое приложение собственную версию этой логики (что еще хуже).
Недостаток этих решений состоит в том, что оба они кооперативны — т.е. работают лишь тогда, когда каждое приложение функционирует по одной и той же системе правил. Кооперативные решения пугающе усложняют сопровождение.
Триггеры INSTEAD OF имеют два недостатка:
•    они работают только на уровне строк, но не на уровне предложений;
•    их можно применять только к представлениям, но не к таблицам.
Второе ограничение вызовет удивительное явление, например, в следующем случае. Допустим, вы записали предложение:
CREATE VIEW emp_view AS SELECT * FROM emp;
3. Некоторые усовершенствования в OracleS	29