Другие вопросы, связанные с использованием триггеров

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

Применение вложенных триггеров

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

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

От того, разрешено ли использование вложенных триггеров в системе (эта опция определяется на уровне системы, а не базы данных; для ее определения применяется программа Management Studio или процедура sp conf igure, и по умолчанию она разрешена).

От установленного лимита вложенности, составляющего 32 уровня.

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

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

Рекурсивный вызов триггеров

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

в таблице, на которой задан триггер) или опосредованно (в результате запуска вложенных трр1ггеров).

Рек)рсивные вызовы триггеров применяются редко. И действительно, по умолчанию возможность рекурсивного вызова триггеров не предусматривается. Тем не менее рекурсивный запуск триггеров позволяет найти вьгход из только что описанной ситуации, в которой применяется вложение триггеров и требуется, чтобы обновление таблицы было выполнено дважды. В отличие от опции, допускающей использование вложения, опция, определяющая возможность применения рекурсии, устанавливается на уровне базы данных; для этого может служить хранимая системная процедура sp dbopt ion.

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

Отладка кода триггеров

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

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

Если отладка триггера с помощью программы Visual Studio производится в целях проверки его работы, используйте операторы PRINT и SELECT для вывода значений, обрабатываемых в триггере. Это позволяет не только узнать, как изменяются значения переменных в ходе выполнения кода, но и получить информацию о том, какие проблемы возникают в ходе рекурсивных (а иногда и вложенных) вызовов.

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

Для определения того, на каком уровне вложенности происходит текущий запуск триггера, можно, в частности, использовать оператор select @@nestlevel.

Но следует учитывать, что в процессе отладки операторы print и операторы select, применяемые для формирования результирующих наборов, могут фактически использоваться исключительно для вывода отладочных данных только на экран (в программе Management Studio) или для создания информационных сообщений (касающихся моделей доступа к данным). Обычно эта особенность процедуры отладки триггеров становится причиной еще более значительных затруднений для разработчика, чем что-либо иное. Кроме того, автор настоятельно рекомендует удалять все указанные операторы, применявшиеся в процессе отладки, сразу после завершения отладки, прежде чем передавать триггеры в эксплуатацию.

Отсутствие возможности предотвратить с помощью триггеров внесение структурных изменений

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

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

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

Но из сказанного выше следует одно предостережение, поскольку в триггерах структурные изменения обнаруживаются только после их запуска. Это означает, что некоторые стр}ктурные изменения могуг прршодить к нарушению работы многочисленных триггеров, но это даже не будет обнаружено до их запуска. Вернее, такое нарушение в работе останется незамеченным до тех пор, пока в тех же триггерах не будет предпринята попытка обратиться к модифицированному объекту (объектам), после чего и появится ошибка, вызванная не до конца продуманными изменениями. Вот тогда-то и возникнут трудности при попытке полностью уяснить для себя, что же было сделано и почему.

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