Триггеры могут вызывать хранимые процедуры. Правила вызова для триггеров в точности такие же, что и для хранимых процедур. Техники обработки исключений обсуждаются в главе 32.
Триггеры могут использовать курсоры, выполнять операции с другими таблицами и отправлять события. Они могут вызывать и обрабатывать исключения, включая те, которые возникли во вложенных процедурах.
Триггеры никогда не вызываются процедурами, другими триггерами или приложениями. Они совсем не поддерживают входные и выходные аргументы.
Особенности PSQL для триггеров
Два особых элемента PSQL доступны триггерам: логические контекстные переменные событий INSERTING, UPDATING и DELETING и контекстные переменные NEW и OLD.
Переменные события
В Firebird появляются логические контекстные переменные INSERTING, UPDATING и DELETING, чтобы поддерживать условные переходы для триггеров, используемых для нескольких событий. Возможным синтаксисом ветвления может быть:
IF ({INSERTING | UPDATING | DELETING}
OR {UPDATING | DELETING | INSERTING}
[OR {DELETING | INSERTING | UPDATING}]) THEN ...
Работа этих полезных предикатов иллюстрируется в дальнейших примерах этой главы.
Переменные NEW и OLD
Контекстные переменные NEW и OLD являются расширениями PSQL, специфичными для триггеров[120]; они позволяют ссылаться на существующие ("старые") и требуемые ("новые") значения каждого столбца. Переменные NEW.* имеют значения в событиях INSERT и UPDATE; переменные OLD.* имеют значения в событиях UPDATE и DELETE, NEW.* в событиях удаления и OLD.* В событиях добавления имеют значение NULL. Применимые значения NEW и OLD доступны для всех столбцов таблицы или просмотра, даже если сами столбцы не указаны в операторе DML.
Значения OLD.* (если доступны) могут использоваться в триггерах как переменные, но изменение значения не влияет на сохраненное старое значение[121]. Значения NEW.* (если доступны) могут использоваться для чтения/записи в фазе BEFORE и только для чтения в фазе AFTER. Если вы хотите манипулировать ими как переменными значениями в триггере AFTER, присвойте их значения локальным переменным и обращайтесь к этим локальным переменным.
Для использования мощи триггеров Firebird в разработке баз данных при отслеживании целостности данных, независимо от людей и внешних программ, переменные NEW и OLD являются основным инструментом. Они могут быть использованы для:
* получения допустимых значений по умолчанию в некоторых условиях;
* проверки и при необходимости преобразования входных данных пользователя;
* получения ключей и значений для выполнения автоматических обновлений в других таблицах;
* реализации автоинкрементных ключей средствами генераторов.
Новые значения для строки могут быть изменены только в действиях BEFORE. Если триггер, запускаемый в фазе AFTER, попытается присвоить значение столбцу NEW, это не даст никакого результата.
Все значения NEW можно перезаписывать в фазе BEFORE, они немедленно принимают новые назначенные им значения. Новая версия записи получит переназначенные значения, только когда все триггеры BEFORE будут завершены. С этого момента значения NEW становятся значениями только для чтения. Следовательно, если у вас несколько триггеров изменяют одни и те же значения NEW, важно, чтобы все они имели различные номера POSITION, правильно упорядоченные.
Рекомендованное использование в Firebird триггеров BEFORE INSERT - реализация в стиле @IDENTITY автоинкрементных первичных ключей. Эта техника проста, и большинство разработчиков Firebird могут написать такие триггеры во сне. Она включает два шага:
1. Создание генератора для генерации уникальных чисел ключа.
2. Написание триггера BEFORE INSERT для таблицы.
Для иллюстрации этой техники мы реализуем автоинкрементный первичный ключ для таблицы CUSTOMER, у которой первичный ключ CUSTOMER_ID- столбец целого типа BIGINT (версия 1.5) или NUMERIC(18,0) (версия 1.0.x). В диалекте 1 базы данных CUSTOMER_ID должен иметь тип INTEGER.
Во-первых, создадим генератор:
CREATE GENERATOR GEN_PK_CUSTOMER;
Затем создадим триггер:
CREATE TRIGGER BI_CUSTOMER FOR CUSTOMER
ACTIVE BEFORE INSERT POSITION 0
AS
BEGIN
IF (NEW.CUSTOMER_ID IS NULL) THEN
NEW. CUSTOMER_ID = GEN_ID (GEN_PK_CUSTOMER, 1) ;
END ^
COMMIT ^
Когда выполняется добавление, CUSTOMER ID сознательно не указывается во входном списке оператора INSERT:
INSERT INTO CUSTOMER (
LAST_NAME,
FIRST_NAME,
...)
VALUES (?, ?, ...);
Без триггера этот оператор вызовет исключение, потому что первичный ключ не может иметь пустого значения. Однако триггер BEFORE INSERT выполняется до проверки этого ограничения, он контролирует, что CUSTOMER ID имеет пустое значение, и выполняет свое действие.
Если триггер может делать это для меня, то вы можете спросить, зачем нужно выполнять проверку на NULL?