Отметим, что внутри триггера не допускается выполнение ряда операций, таких, например, как:
создание, изменение и удаление базы данных; восстановление резервной копии базы данных или журнала транзакций. Выполнение этих команд не разрешено, так как они не могут быть отменены в случае отката транзакции, в которой выполняется триггер. Это запрещение вряд ли может каким-то образом сказаться на функциональности создаваемых триггеров. Трудно найти такую ситуацию, когда, например, после изменения строки таблицы потребуется выполнить восстановление резервной копии журнала транзакций. Программирование триггера
При выполнении команд добавления, изменения и удаления записей сервер создает две специальные таблицы: inserted и deleted. В них содержатся списки строк, которые будут вставлены или удалены по завершении транзакции. Структура таблиц inserted и deleted идентична структуре таблиц, для которой определяется триггер. Для каждого триггера создается свой комплект таблиц inserted и deleted, поэтому никакой другой триггер не сможет получить к ним доступ. В зависимости от типа операции, вызвавшей выполнение триггера, содержимое таблиц inserted и deleted может быть разным:
команда INSERT — в таблице inserted содержатся все строки, которые пользователь пытается вставить в таблицу; в таблице deleted не будет ни одной строки; после завершения триггера все строки из таблицы inserted переместятся в исходную таблицу; команда DELETE — в таблице deleted будут содержаться все строки, которые пользователь попытается удалить; триггер может проверить каждую строку и определить, разрешено ли ее удаление; в таблице inserted не окажется ни одной строки; команда UPDATE — при ее выполнении в таблице deleted находятся старые значения строк, которые будут удалены при успешном завершении триггера. Новые значения строк содержатся в таблице inserted. Эти строки добавятся в исходную таблицу после успешного выполнения триггера. Для получения информации о количестве строк, которое будет изменено при успешном завершении триггера, можно использовать функцию @@ROWCOUNT; она возвращает количество строк, обработанных последней командой. Следует подчеркнуть, что триггер запускается не при попытке изменить конкретную строку, а в момент выполнения команды изменения. Одна такая команда воздействует на множество строк, поэтому триггер должен обрабатывать все эти строки. Если триггер обнаружил, что из 100 вставляемых, изменяемых или удаляемых строк только одна не удовлетворяет тем или иным условиям, то никакая строка не будет вставлена, изменена или удалена. Такое поведение обусловлено требованиями транзакции — должны быть выполнены либо все модификации, либо ни одной. Триггер выполняется как неявно определенная транзакция, поэтому внутри триггера допускается применение команд управления транзакциями. В частности, при обнаружении нарушения ограничений целостности для прерывания выполнения триггера и отмены всех изменений, которые пытался выполнить пользователь, необходимо использовать команду ROLLBACKTRANSACTION. Для получения списка столбцов, измененных при выполнении команд INSERT или UPDATE, вызвавших выполнение триггера, можно использовать функцию COLUMNS_UPDATED (). Она возвращает двоичное число, каждый бит которого, начиная с младшего, соответствует одному столбцу таблицы (в порядке следования столбцов при создании таблицы).
Если бит установлен в значение «1», то соответствующий столбец был изменен. Кроме того, факт изменения столбца определяет и функция UPDATE (имя_столбца).Для удаления триггера используется командаDROPTRIGGER {имя_триггера} [,…n]Заключение
Триггеры — это мощный механизм. Основным преимуществом триггеров является то, что создаваемые с их помощью деловые правила можно хранить в базе данных и применять при каждой операции добавления или обновления. Это позволяет существенно уменьшить размеры прикладной программы. Однако у триггеров имеется и ряд недостатков, а именно: Сложность базы данных. Когда деловые правила становятся частью базы данных, она значительно усложняется. Пользователи, которые рассчитывали создавать на основе этой базы данных маленькие, специализированные приложения, могут столкнуться с тем, что программная логика триггеров делает эту задачу гораздо более сложной. Скрытия логика. Когда деловые правила скрыты в базе данных, программы, осуществляющие, казалось бы, обычные обновления данных, могут в действительности привести к выполнению огромного объема вычислений. У программиста исчезает возможность управлять всеми процессами, происходящими в базе данных, поскольку программные запросы могут вызывать выполнение различных скрытых действий.
Список литературы
Атре Ш. Структурный подход к организации базы данных. — М.: Финансы и статистика, 1983. — 312 с. Гусева Т. И., Башин Ю. Б. Проектирование баз данных в примерах и задачах. — М.: Радио и связь, 1992.
— 160 с., ил. Двуреченский С. В. Концептуальное проектирование баз данных к АСУ. — М.: ЦНИИатоминформ, 1986. — 121 с. Дейт К.
Введение
в системы баз данных. — К.: Диалектика, 1998
Карпова Т. С. Базы данных: модели, разработка, реализация. — СПб.: Питер, 2001. — 304с. Карпова Т. С. Базы данных: модели, разработка, реализация. -СПб.: Питер, 2002. — 304с.:
ил. Карпова Т. С. Базы данных: модели, разработка. — СПб.: Питер, 2001, 304 с. Кириллов В. В. Основы проектирования баз данных. ;
М.: Финансы и статистика, 1997. — 204 с. Коннолли Т., Бегг К., Страчан А. Базы данных: проектирование, реализация, сопровождение. Теория и практика. — М.: Вильямс, 2000. -
1120 с.: ил. Кренке Д. Теория и практика построения баз данных: [пер.
с англ] / Д. Кренке. — 9 — е изд. ;
СПб.: Питер, 2005. — 858 с. Тиори Т., Фрай Дж. Проектирование структур баз данных: В 2-х кн. Пер. с англ. — М.: Мир, 1985.
— 287 с., ил. Ульман Дж., Уидом Дж.
Введение
в системы баз данных. — М.: Лори, 2000. — 374с. Хансен Г., Хансен Д. Базы данных: разработка и уравление.
— М.: БИНОМ, 1999
Шкарина Л. Н. Язык SQL: Учебный курс. — СПб.: Питер, 2001. — 592с.:
ил.
