Триггеры в sql: CREATE TRIGGER (Transact-SQL) — SQL Server

Почему следует избегать триггеров | Windows IT Pro/RE

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

Проблемы с триггерами

Триггеры представляют собой специализированный код, который срабатывает при инициирующем событии внутри базы данных. В самом SQL Server есть два основных типа триггеров: триггеры Data Definition Language, или языка определения данных (DDL), и Data Manipulation Language, или языка управления данными (DML). Триггеры DDL, как следует из названия, работают в том случае, когда выполняются события языка определения данных (например, создание нового года, структур, имен входа и т. д.). Этот вид триггеров мы здесь рассматривать не будем. Нас интересуют триггеры DML, которые выполняются при изменении данных или управлении ими, в контексте перечисленных ниже проблем.

• Неизвестность. При отладке или устранении неисправностей, а также при поиске причины ошибки или изменений данных внутри сложных систем, триггеры слишком удобны для разработчиков (и даже администраторов), чтобы забывать о них. Представим себе ситуацию: разработчики знают, что определенной части приложения или кода поручена обработка, скажем, вставка в конкретной таблице, и продолжают сталкиваться с некоторыми конечными значениями, отличными от тех, что были при отправке. Обычно в таких случаях предполагают, что есть некая ошибка в коде, — пока не вспомнят, что триггер, развернутый когда-то в прошлом, просто молчаливо наблюдает за всеми INSERT и изредка управляет ими, выравнивая данные по бизнес-правилам, которые уже не актуальны. Эта же проблема с триггерами типа «развернуть и забыть» может, в свою очередь, доставить немало хлопот при устранении неполадок.
• Сложности. Помимо того, что существуют веские основания избегать включения бизнес-логики в базу данных, факт остается фактом: триггеры на самом деле сложнее, чем кажется. Например, одна из распространенных проблем с триггерами заключается в том, что разработчики, их создающие, мыслят в рамках одной строки, модифицируемой в триггере. Также нередко разработчики ошибочно создают триггеры с неверной скалярной семантикой, что вызывает проблемы, когда оператор вроде UPDATE затрагивает несколько строк. Еще один вопрос, должен ли триггер DML быть запущен до, после или вместо DML — в результате труднее определить, что происходит, когда есть триггеры.
• Производительность и масштабируемость. Триггеры, по определению, выполняются всякий раз, когда работает операция DML. С помощью логики и дополнительной фильтрации определяется, должен ли триггер игнорировать, блокировать или модифицировать DML при попытках изменения. Кроме того, свойства DELETED и INSERTED для псевдотаблиц работают, и нередко можно наблюдать операции с триггерами, требующими более гранулированных и дорогих блокировок, чем обычно. Другими словами, таблица без триггеров всегда будет вести себя лучше, чем таблица с триггерами — это ключевой фактор, когда речь идет о масштабируемости. Хотя триггер может прекрасно работать на небольших базах данных, по мере того, как количество данных и таблиц увеличивается, триггеры выполняют все больше блокировок, повышают нагрузку, снижают производительность и вызывают проблемы с масштабируемостью. Действительно, в некоторых самых сложных случаях, с которыми я когда-либо сталкивался, были со всей тщательностью устроенные триггеры, которые только усугубляли ситуацию.

Когда использовать триггеры

Учитывая, что триггеры сложны и велика вероятность потерпеть неудачу при устранении неполадок и столкнуться с серьезными проблемами в крупных параллельных системах, возникает вопрос: какова их роль в системе? Лично я не сторонник их применения для чего бы то ни было. По большому счету, основная часть логики, которую они реализуют, может быть перемещена в хранимые процедуры или в любой код, уже служащий для модифицирования данных. На мой взгляд, использование триггеров сигнализирует о системной или архитектурной проблеме, поскольку разработчики зачастую начинают применять триггеры в качестве «горячей клавиши», чтобы обеспечить выполнение бизнес-правил с использованием таблицы вместо модифицирующего кода, «захватывающей» всю логику и все функции. В некотором отношении это равносильно попытке написать пре- и пост-фильтры к веб-запросам для вставок или изменений верхних и нижних колонтитулов HTML, вместо того чтобы найти код создания этих объектов и модифицировать его, если необходимо.

Если отвлечься от перечисленных соображений, можно найти одно место, где использование триггеров имеет смысл: это аудит. Аудит необходим для соблюдения законодательных требований, которые обычно слишком обширны для триггеров и ими, как правило, должны заниматься дорогостоящие решения аудита сторонних фирм. Однако для простых сценариев, где вам нужно следить за изменением данных в определенных строках, можно настроить простые триггеры, которые будут захватывать и направлять строки INSERTED, DELETED и UPDATED в таблицу TableName_Audit. Это позволит отслеживать значения и метаданные о том, кто и когда выполнил операцию, без обременительных расходов. Это вовсе не означает, что использование триггеров избавит вас от всех проблем, но, на мой взгляд, это единственная область, где они сыграют свою роль. Если вы все же захотите использовать триггеры, поймите, что операции INSERT, UPDATE, а также DELETE и MERGE изменят единовременно более чем одну строку. Представьте, что ваши аудиторские таблицы будут становиться все больше, а времени на их заполнение строками в конечном итоге потребуется слишком много, если индексация этих таблиц аудита должным образом не оптимизирована для операторов INSERT. В целом, я настоятельно рекомендую не использовать триггеры, учитывая проблемы, которые просто неизбежны.

Триггеры

Триггер
— это
особая хранимая процедура, которая
вызывается в ответ на модификацию
содержимого базы данных. В отличие от
хранимых процедур, созданных с помощью
инструкции create
procedure,
триггер
нельзя выполнить с помощью инструкции
call
или
EXECUTE.
Каждый триггер связывается с определенной
таблицей
базы данных, и СУБД сама выполняет его,
когда данные в таблице изменяются
инструкцией
INSERT,
DELETE
ИЛИ UPDATE).

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

Инструкция
create
trigger
используется
в большинстве ведущих СУБД для создания
нового триггера, включаемого в базу
данных. Она назначает триггеру имя,
указывает,
с какой таблицей его следует связать и
в ответ на какие события он должен
вызываться.
Далее
следует тело триггера, которое, как
и у обычных хранимых процедур, определяет
последовательность инструкций,
выполняемых
при его вызове.

Контрольные вопросы

1. Особенности
   языка SPL
   в диалекте Watcom-SQL.

2. Особенности
   языка SPL
   в диалекте Transact-SQL.

3. Особенности
   оператора CASE
   в Transact-SQL.

4. Дайте определения
   триггера.

Преимущества и
недостатки триггеров

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

• Контроль
изменений. Триггер
может отслеживать и отменять определенные
изменения,
не разрешаемые в конкретной базе данных.

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

• Поддержка
  целостности. Триггер
  может поддерживать более сложные связи
  между
  данными, чем те, которые могут быть
  выражены простыми ограничениями на
  значения столбцов и условиями ссылочной
  целостности. Для сохранения этих связей
  может потребоваться выполнение
  последовательности инструкций SQL,
  иногда даже с использованием конструкций
  IF.
  . .then.
  .
  .ELSE.

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

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

Главным
недостатком триггеров является их
влияние на производительность операций
с базой данных. Если с некоторой таблицей
связан триггер, СУБД выполняет
его каждый раз, когда эта таблица
обновляется. И если от базы данных
требуется очень
быстрое добавление и модификация больших
объемов данных, триггеры могут оказаться
неприемлемым решением. Тем более что
перед проведением пакетных операций
данные могут быть проверены заранее и
наверняка будут удовлетворять всем
требованиям целостности. По этой причине
некоторые СУБД позволяют избирательно
активизировать и отключать триггеры
по мере необходимости.

Триггеры
в диалекте Transact—SQL

В
Transact-SQL
триггеры создаются инструкцией create
trigger
(как
в Microsoft
SQL
Server,
так и в Sybase
Adaptive
Server).

Специально
для триггеров Transact-SQL
определяет две виртуальные таблицы,
структура
которых идентична структуре таблицы,
с которой связан триггер. Эти таблицы
называются
deleted
и
inserted.
Они
заполняются строками из модифицируемой
таблицы,
причем их конкретное содержимое зависит
от выполняемой операции:

• delete
  —
  все строки, удаленные из связанной
  таблицы, помещаются в таблицу deleted,
  таблица
  inserted
  пуста;

• INSERT
  — все строки, добавленные в связанную
  таблицу, помещаются в таблицу inserted,
  таблица
  DELETED
  пуста;

• update
  —
  для каждой строки связанной таблицы,
  измененной инструкцией update,
  ее
  исходная
  версия
  помещается в таблицу deleted,
  а
  новая
  версия
  — в таблицу inserted.

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

Для
триггеров, связанных с инструкцией
UPDATE,
в Transact-SQL
предусмотрена возможность выяснить,
какие именно столбцы таблицы были
изменены, и в ответ выполнить
соответствующие действия. Для этого в
триггерах может использоваться
специальная
форма инструкции IF
— IF
update.

Триггеры
в диалекте Informix

В
Informix
триггеры тоже создаются с помощью
инструкции create
trigger.
Как
и в Transact-SQL,
эта инструкция определяет имя триггера,
таблицу, с которой он
связан, и действия, в ответ на которые
он выполняется.

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

• before
  —
  триггер вызывается перед
  выполнением
  любых изменений, когда ни одна
  строка связанной таблицы еще не
  модифицирована;

• after
  —
  триггер вызывается после
  выполнения
  всех изменений, когда все строки
  связанной
  таблицы уже модифицированы;

• FOR
  each
  ROW
  — триггер вызывается для
  каждой модифицируемой строки, и
  ему доступны
  как старая, так и новая версия этой
  строки.

Для
каждого из этих этапов в триггере может
быть задана отдельная последовательность
действий.

В
отличие от других СУБД, Informix
ограничивает набор действий, которые
могут выполняться триггером. Допускаются
только.

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

Триггеры
в диалекте Oracle
PL/SQL

В
Oracle
возможности создания триггеров шире,
чем в Informix
и Transact-SQL.
В этой СУБД для создания триггеров тоже
используется инструкция create
trigger,
но
структура ее иная. Подобно Informix,
она позволяет связать триггер с различными
этапами обработки запроса, но на трех
разных уровнях:

• Триггер
  уровня инструкции (statement)
  вызывается
  один раз для каждой инструкции SQL.
  Он может быть вызван до или после ее
  выполнения.

• Триггер
  уровня записи (row)
  вызывается
  один раз для каждой модифицируемой
  записи.
  Он также может вызываться до или после
  модификации;

• Замещающий
триггер (instead
OF)
выполняется вместо инструкции SQL.
С помощью такого триггера можно
отслеживать попытки приложения или
пользователя обновить,
добавить или удалить записи и вместо
этих действий выполнять свои собственные.
Вы можете определить триггер, который
должен выполняться вместо некоторой
инструкции или вместо каждой попытки
изменения строки таблицы. Всего
получается 14 различных типов триггеров.
Двенадцать из них — это комбинации
операций insert,
update
и
delete
с
опциями before
или
after
на
уровне row
или
statement
(3×2*2)
плюс еще два триггера типа instead
of
уровня
row
и
statement.
Однако
на практике в реляционных базах данных
Oracle
триггеры типа instead
OF
применяются редко; они были введены в
Oracle8
для поддержки ее некоторых
новейших объектно-ориентированных
функций.

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

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

В
различных
СУБД
эта
проблема решается по-разному, в
одних
системах ограничивается
набор действий, которые могут выполняться
триггерами. В других предусмотрены
встроенные функции, которые позволяют
триггеру определить уровень вложенности,
на котором он работает. В-третьих, имеются
системные установки, определяющие,
допустимо ли «каскадирование»
триггеров. А есть системы, которые
ограничивают
уровень вложенности каскадно выполняемых
триггеров.

Вторая
проблема триггеров состоит в том, что
при пакетных операциях с базой данных,
например при внесении в нее больших
объемов информации, триггеры сильно
замедляют работу базы данных. Поэтому
некоторые СУБД позволяют избирательно
отключать триггеры в таких ситуациях.
В Oracle,
например, предусмотрена такая форма
инструкции alter
trigger:

ALTER
TRIGGER
TEST
DISABLE;

Аналогичную
возможность обеспечивает инструкция
create
trigger
в
Informix.

Рассмотри
пример создания триггера в СУБД Sybase
SQL
Anywhere.

Процедуры
и триггеры хранят операторы SQL
и управляющие операторы в базе данных
для их использования любыми приложениями.

Они улучшают
безопасность, эффективность и
стандартизацию баз данных.

Пример триггера
уровня записи INSERT

Показанный ниже
триггер проверяет, что бы дата рождения
(birthdate) введенная для нового сотрудника
была приемлема.

CREATE
TRIGGER check_birth_date

AFTER
INSERT ON Employee

REFERENCING
NEW AS new_employee

FOR
EACH ROW

BEGIN

DECLARE
err_user_error EXCEPTION

FOR
SQLSTATE ‘99999’;

IF
new_employee. birth_date > ‘June 6, 1994’ THEN

SIGNAL
err_user_error;

END
IF;

END

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

Конструкция
REFERENCING NEW AS new_employee позволяет операторам
в тексте триггера ссылаться на данные
в новой записи используя алиас
new_employee.

Для оператора
INSERT который добавляет несколько записей
в таблицу employee, триггер check_birth_date
вызывается для каждой новой записи.
Если триггер завершается неудачно хотя
бы на одной записи, все изменения
сделанные оператором INSERT отменяются.

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

CREATE
TRIGGER mytrigger BEFORE INSERT ON Employee

Выражение REFERENCING
NEW позволяет ссылаться на значения
добавляемой записи; и эта ссылка не
зависит от типа триггера (BEFORE or AFTER).

Пример триггера
уровня записи для операции DELETE.

CREATE
TRIGGER mytrigger BEFORE DELETE ON employee

REFERENCING
OLD AS oldtable

FOR
EACH ROW

BEGIN

…

END

Выражение REFERENCING
OLD позволяет ссылаться в модуле триггера
на значения в удаляемой записи с помощью
алиаса oldtable.

Триггер легко
преобразовать к типу after путем изменения
первой строки примера.

CREATE
TRIGGER mytrigger BEFORE DELETE ON employee

Выражение REFERENCING
OLD не зависит от типа триггера (BEFORE or
AFTER).

Пример триггера
уровня оператора для операции UPDATE.

CREATE
TRIGGER mytrigger AFTER UPDATE ON employee

REFERENCING
NEW AS table_after_update

OLD
AS table_before_update

FOR
EACH STATEMENT

BEGIN

…

END

Выражения REFERENCING
NEW и REFERENCING OLD позволяют в тексте триггра
ссылаться на старые и новые значения
записи, для которой выполняется операция
UPDATE. Столбцы с новыми значениями доступны
через алиас table_after_update, столбцы со старыми
значениями через алиас table_before_update.

Выражения REFERENCING
NEW и REFERENCING OLD имеют разный смысл для
триггеров уровня оператора и триггеров
уровня записи. Для триггеров уровня
оператора REFERENCING OLD или NEW являются
алиасами таблиц, в триггере уровня
записи они ссылаются на изменяемую
запись.

Контрольные вопросы

1. Перечислите
   преимущества и недостатки триггеров.

2. Особенности
   реализации триггеров в Transact-SQL.

3. Особенности
   реализации триггеров в СУБД Informix.

4. Особенности
   реализации триггеров в Oracle
   PL/SQL.

5. Укажите
   последовательность создания триггера
   в Sybase
   Sql
   Anywhere.

Тестирование триггеров SQL-сервера (как выполнять)

RelationalDBDesign

• Карта сайта

Триггеры SQL-сервера
«Пред.
Следующий»

• Бизнес-правила
• Блокировка транзакции
• Изоляция транзакций — викторина
• Тестирование обработки ошибок
• Взаимодействие с сервером
• Назначение переменных использования
• Ошибки вызова SQL
• Функции SQL Server
• Триггеры SQL-сервера
• Тест триггеров SQL
• Обеспечение соблюдения бизнес-правил
• Создание триггеров — упражнение
• Тестирование триггера SQLserver
• Хранимые процедуры
• Что такое SP
• Обеспечение соблюдения бизнес-правил
• Создание SP
• Определяемый пользователем SP
• Хранимые процедуры — упражнение
• Процедуры модификации
• Удаление хранимых процедур
• Расширенная система SP
• Обработка ошибок
• Использование выходных параметров
• Выполнение хранимых процедур
• Тестирование хранимых процедур
• Различное заключение SP
• Хранимая процедура — Викторина
• Доступ к удаленным данным
• Сервер управления предприятием
• Добавление удаленного входа

Урок 10	Тестирование триггеров
Цель	Опишите, как тестировать ваши триггеры.

Вы можете подумать, что тестирование ваших триггеров сложно. Однако это не могло быть дальше от истины. Чтобы протестировать триггер, вы просто запускаете оператор Transact-SQL, который нарушает правила вашего триггера, и смотрите, как реагирует SQL Server.
Ранее в этом модуле мы модифицировали триггер trgSalary таким образом, что теперь требуется авторизация для любой зарплаты, превышающей 150 000 долларов США.
Поскольку trgSalary является триггером INSERT, его можно протестировать с помощью ВСТАВКА
Оператор Transact-SQL, убедившись, что он охватывает все случаи, связанные с назначением триггера. Слайд-шоу ниже исследует эти утверждения:

Выдать инструкцию Transact SQL

После выполнения этих тестов замените каждый из них оператором UPDATE или DELETE Transact-SQL. Эти операторы должны быть разрешены, потому что наш триггер является всего лишь триггером INSERT .
На следующем уроке будет рассмотрена информация, изложенная в этом модуле.

Триггеры DML часто используются для обеспечения соблюдения бизнес-правил и целостности данных ^[1] . SQL Server обеспечивает декларативную ссылочную целостность с помощью операторов ALTER TABLE и CREATE TABLE.
Однако DRI не обеспечивает ссылочную целостность между базами данных . Ссылочная целостность относится к правилам отношений между первичными и внешними ключами таблиц.
Чтобы обеспечить ссылочную целостность , используйте ограничения PRIMARY KEY и FOREIGN KEY в ALTER TABLE и CREATE TABLE.
Если в таблице триггеров существуют ограничения, они проверяются после выполнения триггера INSTEAD OF и перед выполнением триггера AFTER. Если ограничения нарушаются, действия триггера INSTEAD OF отменяются, а триггер AFTER не срабатывает.

Вербунг

Первый и последний триггеры AFTER, которые должны выполняться для таблицы, можно указать с помощью sp_settriggerorder . В таблице можно указать только один первый и один последний триггер AFTER для каждой операции INSERT, UPDATE и DELETE.
Если в той же таблице есть другие триггеры AFTER, они выполняются случайным образом.
Если инструкция ALTER TRIGGER изменяет первый или последний триггер, первый или последний набор атрибутов измененного триггера отбрасывается, и значение порядка необходимо сбросить с помощью sp_settriggerorder. Триггер AFTER выполняется только после успешного выполнения триггерного оператора SQL. Это успешное выполнение включает в себя все ссылочные каскадные действия и проверки ограничений, связанные с обновленным или удаленным объектом. Триггер AFTER не будет рекурсивно запускать триггер INSTEAD OF для той же таблицы.

Если триггер INSTEAD OF, определенный для таблицы, выполняет инструкцию для таблицы, которая обычно снова запускает триггер INSTEAD OF, триггер не вызывается рекурсивно.
Вместо этого оператор обрабатывается так, как если бы в таблице не было триггера INSTEAD OF, и запускает цепочку операций ограничения и выполнения триггера AFTER.
Например, если триггер определен как триггер INSTEAD OF INSERT для таблицы и триггер выполняет оператор INSERT для той же таблицы, оператор INSERT, выполняемый триггером INSTEAD OF, не вызывает этот триггер снова.
INSERT, выполняемый триггером, запускает процесс выполнения ограничивающих действий и срабатывания любых триггеров AFTER INSERT, определенных для таблицы.

Werbung

Werbung

Werbung

Werbung

Werbung

Werbung

Werbung

9000 2 Вербунг

Если триггер INSTEAD OF, определенный для представления, выполняет оператор для представления, который обычно снова запускает триггер INSTEAD OF, он не вызывается рекурсивно. Вместо этого оператор разрешается как модификации базовых таблиц, лежащих в основе представления. В этом случае определение представления должно соответствовать всем ограничениям для обновляемого представления.
Определение обновляемых представлений см. в разделе «Изменение данных через представление».

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

[1]
целостность данных: Целостность данных — это поддержание и гарантия точности и непротиворечивости данных на протяжении всего их жизненного цикла, а также критический аспект проектирования, реализации и использования любой системы, которая хранит, обрабатывает или извлекает данные.

Триггеры SQL-сервера
«Пред.
Следующий»

Триггеры MySQL

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

MySQL поддерживает триггеры, которые вызываются в ответ на событие INSERT , UPDATE или DELETE .

Стандарт SQL определяет два типа триггеров: триггеры уровня строки и триггеры уровня оператора.

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

MySQL поддерживает только триггеры на уровне строк. Он не поддерживает триггеры на уровне операторов.

Преимущества триггеров

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

Недостатки триггеров

• Триггеры могут предоставлять только расширенные проверки, а не все проверки. Для простых проверок можно использовать ограничения NOT NULL , UNIQUE , CHECK и FOREIGN KEY .
• Устранение неполадок с триггерами может быть затруднено, поскольку они автоматически выполняются в базе данных, которая может быть невидима для клиентских приложений.
• Триггеры могут увеличивать нагрузку на сервер MySQL.

Управление триггерами MySQL

• Создание триггеров — описание шагов по созданию триггера в MySQL.
• Сбросить триггеры — показать вам, как сбросить триггер.
• Создайте триггер BEFORE INSERT — покажите, как создать триггер BEFORE INSERT для поддержки сводной таблицы из другой таблицы.