Как уже говорилось, целостность данных часто связана с порядками и правилами в конкретной организации. Например:
· клиенты не могут размещать заказы на сумму, превышающую их кредит;
· заказы хранятся в БД в течении определенного срока, а затем аннулируются;
· заказы на крупные суммы должны храниться в отдельной таблице для согласования с менеджером по продажам.
В стандарте SQL92 определено, что эти деловые правила выходят за рамки языка и должны учитываться в прикладных программах. Перенос нагрузки на приложения имеет следующие недостатки:
· дублирование программных фрагментов;
· недостаточная согласованность, связанная с отличиями в программировании правил в разных приложениях;
· трудность сопровождения при изменении правил.
Понятие триггер является относительно простым. С любым событием, вызывающим изменение таблицы, пользователь может связать сопутствующее действие, которое СУБД должна выполнять при каждом возникновении события. Возможны три таких события, возникающие при попытках изменить содержимое таблицы операторами INSERT, DELETE и UPDATE. Действие, вызываемое событием, задается как последовательность операторов SQL и хранится в БД.
Поддержка механизма триггеров появилась во многих СУБД. Наряду с очевидными достоинствами, триггеры имеют и недостатки. Программная логика триггеров не всегда доступна рядовым пользователям и способна усложнить простые на первый взгляд приложения, приводя к большому объему вычислений. У программиста исчезает возможность управлять всеми процессами в БД. По этим причинам триггеры были “узаконены” только в стандарте SQL99.
Триггеры представляют собой частный случай хранимых процедур, то есть стандартных программ, хранящихся в БД и доступных всем приложениям. Хранимые процедуры обеспечивают выполнение распространенных функций, связанных с конкретной БД. В отличие от триггеров, хранимые процедуры вызываются явно.