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

Проверим работу триггера, вызвав на вьшолнение тестовый сценарий:

PRINT Now making the change UPDATE Production.ProductInventory SET Quantity = Quantity + 7 WHERE ProductID = 1 AND LocationID = 50

PRINT The values before the change are: SELECT ProductID, LocationID, Quantity FROM Production.ProductInventory WHERE ProductID = 1 AND LocationID = 50

PRINT Now making the change UPDATE Production.ProductInventory SET Quantity = Quantity - 7 ШЕКЕ ProductID = 1 AND LocationID = 50

PRINT The values after the change are: SELECT ProductID, LocationID, Quantity FROM Production.ProductInventory WHERE ProductID = 1 AND LocationID = 50

SELECT * FROM Production.InventoryAudit

После этого появляется возможность использовать данные, полученные до и после внесения изменений, чтобы проверить, правильно ли введены в таблицу аудита данные аудита:

The values before the change are: ProductID LocationID Quantity

1 50 346

(1 row(s) affected)

Now making the change

(1 row(s) affected)

(1 row(s) affected)

The values after the change are:

ProductID LocationID Quantity

1 50 339

(1 row(s) affected)

TransactionID ProductID NetAdjustment ModifiedDate

1 1-7 2006-04-12 09:54:29.187

2 1-7 2006-04-12 09:54:29.200

(1 row(s) affected)

Использование триггеров для формирования определяемых пользователем сообщений об ошибках

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

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

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

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

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

Обновление итоговой информации.

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

Выставление флажков для проверки условий.

Обновление итоговой информации

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

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

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

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

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

Накопление данных в денормализованных таблицах в целях подготовки отчетов

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

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

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