Конструкция FOR (вместо нее вполне допустимо применять конструкцию AFTER) позволяет указать, какое действие (действия) приводит к запуску триггера. Может быть предусмотрен запуск триггера при выполнении оператора INSERT, UPDATE или DELETE либо любого сочетания этих трех операторов. В качестве примера ниже приведено несколько различных вариантов конструкции FOR.

AFTER INSERT, DELETE или

AFTER UPDATE, INSERT или

AFTER DELETE

Как было указано в предыдущем разделе, посвященном описанию конструкции ON, триггеры, объявляемые с конструкцией FOR или AFTER, могуг быть закреплены только за таблицами; закрепление этих триггеров за представлениями не допускается (дополнительная информация по этой теме приведена при описании триггеров INSTEAD OF).

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

Триггер insert

Код любого триггера, который объявлен с ключевыми словами FOR INSERT, вызывается на выполнение каждый раз, когда кто-либо вставляет новую строку в таблицу, за которой закреплен триггер. Для каждой вставляемой строки СУБД SQL Server создает копию этой новой строки и вставляет ее в специальную таблицу, существующую только в области определения данного триггера. Эта таблица называется INSERTED, и дополнительные сведения о ней будут приведены в ходе описания различных тем настоящей главы. Наиболее важная особенность таблицы INSERTED состоит в том, что она сохраняется только до тех пор, пока действует триггер, с которым она связана. Следует еще раз подчеркнуть, что таблица INSERTED существует только с момента запуска триггера и до момента завершения его вьшолнения.

Триггер delete

Триггеры DELETE действуют во многом аналогично триггерам INSERT, не считая того, что связанная с ними таблица INSERTED пуста (и это очевидно, поскольку в триггерах DELETE осуществляется удаление, а не вставка строк, поэтому отсутствуют строки, копия которьпс должна находиться в таблице INSERTED). Вместо этого копия каждой удаленной строки вставляется в другую таблицу, называемую DELETED. Эта таблица, как и таблица INSERTED, имеет область определения, которая ограничивается исключительно продолжительностью существования триггера.

Триггер UPDATE

Триггеры UPDATE имеют свою специфику. Запуск кода триггера, объявленного с ключевыми словами FOR UPDATE, происходит при каждом внесении изменения в строку, существующую в таблице. А особенность триггера UPDATE состоит в том, что отсутствует такая таблица, как UPDATED. Вместо этого в СУБД SQL Server операция модификации каждой строки трактуется так, как будто удаляется существующая строка и вставляется полностью новая. Вполне очевидно, что из этого следует такой вывод: триггер, объявленный с ключевыми словами FOR UPDATE, обслуживается с помощью не одной, а двух специальных таблиц, INSERTED и DELETED. Безусловно, в процессе работы количество строк в этих двух таблицах полностью совпадает.

Ключевое СЛОВО with append

Ключевое слово WITH APPEND предназначено для устранения некоторых ограничений предьщущих версий SQL Server, поэтому после перехода на использование более современных версий необходимость в его применении отпадает. Ключевое слово WITH APPEND используется, только если СУБД эксплуатируется в режиме совместимости с версией 6.5 (такой режим может бьггь задан с помощью процедуры sp dbcmpt level).

В версии SQL Server 6.5 и предыдущих верси51х не была предусмотрена возможность использования несколькрсх триггеров одного и того же типа применительно к какой-либо отдельной таблице. Например, если уже был объявлен триггер trgCheck, предназначенный для обеспечения целостности данньгх при выполнении операций обновления и вставки, то исключалась возможность создать отдельный триггер для каскадных обновлений. После создания единственного триггера для обновления (или вставки, или удаления) на это все заканчивалось, поскольку невозможно было предусмотреть использование еще одного триггера для выполнения действия такого же типа.

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

Наконец, после выпуска версии SQL Sender 7.0 правила применения триггеров существенно изменились. При использовании этой версии больше не приходилось задумываться над тем, какое количество триггеров разрешается использовать по отношению к запросу на выполнение действия одного типа; при желании можно было применять несколько такргх триггеров. Тем не менее при эксплуатации базы данных в режиме совместимости с версией 6.5 возникали проблемы, поскольку база данных по-прежнем\ эксплуатировалась на основании того требования, что применительно к каждой конкретной таблице должен быть задан только один триггер определенного типа.

Ключевое слово WITH APPEND позволяет обойти так)то проблему, поскольку сл)-жит для СУБД SQL Server указанием на то, что этот новый триггер долясен быть введен в действие, даже несмотря на то, что на таблице уже определен триггер такого же типа. В связи с этим после осуществления соответствтощего триггерного действия (выполнения оператора INSERT, UPDATE или DELETE) происходит запуск и старого, и нового триггеров. Благодаря этому появляется возможность использовать сочетание средств старой и новой версий.

Опция not for replication

Введение в действие опции NOT FOR REPLICATION приводит к небольшом) изменению правил, в соответствии с которыми определяется время запуска триггера. Если эта опция введена в действие, то триггер не запускается каждый раз, когда таблица модифицируется в связи с выполнением задачи, относящейся к репликации. Дело в том, что обычно триггер запускается (для выполнения служебных действий, обеспечения каскадного распространения операций и т.д.) во время модификации оригинала таблицы, поэтому нет смысла запускать его снова.

Ключевое слово as

Так же как и в объявлениях хранимых процед), за ключевым словом AS следует наиболее важная часть оператора. С помощью ключевого слова AS в СУБД SQL Server передаются сведения о том, запуск какого кода должен быть осуществлен при вызове триггера. Дальнейшее описание в настоящей главе посвящено только этой части триггера, фактически представляющей собой сценарий.

Использование триггеров для реализации правил обеспечения целостности данных

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

Применяются такие бизнес-правила, которые требуют обращения к данным еще в одной, отдельной таблице.

Согласно используемому бизнес-правилу, должна проводиться проверка дельты обновления (различия между предыдущим и последующим состояниями данных),

Должно быть предусмотрено формирование сообщений об ошибках, определяемых пользователем.

Итоговая таблица с рекомендациями по использованию различных механизмов обеспечения целостности данньгх приведена в конце главы 5 (см. табл. 5.3).

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