Глава 13

Триггеры

Эта глава посвящена очень важной теме - описанию триггеров.

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

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

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

Краткое ознакомление с понятием триггера (очень компактная и немногословная версия описания).

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

Использование триггеров для создания мощных правил проверки целостности данных.

Использование триггеров INSTEAD OF для создания более сложных обновляемых представлений.

Другие общие способы использования триггеров.

Управление последовательностью запуска триггеров.

Проблемы повышения производительности.

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

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

Ниже перечислены некоторые наиболее характерные области применения триггеров.

Принудительная поддержка правил ссылочной целостности. Безусловно, при любой возможности рекомендуется использовать декларативные средства обеспечения ссылочной целостности (Declarative Referential Integrity- DRI), но во многих случаях средства DRI не позволяют справиться с работой (например, с их помощью невозможно обеспечить поддержку ссылочной целостности с охватом нескольких баз данных и тем более серверов, они не поддерживают многие сложные типы связей и т.д.). В последнее время триггеры все реже применяются для поддержки правил ссылочной целостности, но еще не следует полностью исключать это направление использования триггеров.

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

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

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

Кроме того, предусмотрена возможность применения триггеров нового типа (триггеров DDL), которые позволяют следить за изменениями в структуре таблиц. По-видимому, с этой необходимостью приходится сталкиваться достаточно редко (как уже было сказано, триггеры DDL - это триггеры нового типа, поэтому требуется определенное время для проверки целесообразности их использования).

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

Общее определение понятия триггера

Триггер - это хранимая процедура особого типа, вызываемая на выполнение в ответ на определенные события. Триггеры подразделяются на два основных типа: триггеры языка определения данных (Data Definition Language - DDL) и триггеры языка манипулирования данными (Data Manipulation Language - DML).

Триггеры DDL активизируются в ответ на внесение каких-либо изменений в структуру базы данных теми или другими пользователями (под этим подразумеваются изменения, осуществляемые с помощью операторов CREATE, ALTER, DROP и т.п.). Триггеры этого типа были впервые введены в версии SQL Server 2005. Без триггеров DDL очень трудно обойтись в некоторых инсталляциях (особенно если инсталлированные программные средства должны обеспечивать высокую степень защиты), но в целом они имеют довольно узкую область применения. В общем, чаще всего приходится сталкиваться с тем, что триггеры DDL используются, если есть необходимость чрезвычайно строго следить за внесением изменений в структуру базы данньгх и регистрировать хронологию этих изменений. Описание триггеров этого типа будет приведено в последнюю очередь.

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

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

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

Возможность закрепления триггеров за конкретными операторами определяется тем, что в языке SQL предусмотрены три типа запросов, предназначенных для внесения изменений в данные. В связи с этим предусмотрены три основных типа триггеров, а также дополнительные типы, создаваемые с учетом одновременного возникновения и совпадения событий, обусловленных выполнением запросов этргх типов. Итак, в конечном итоге могут быть созданы триггеры, активизируемые при выполнении операций вставки, обновления и (или) удаления (события, при обнаружении которых происходит запуск триггера, могут дополнительно уточняться и согласовываться).