Ответ
Триггер — это хранимая процедура в базе данных, которая автоматически выполняется в ответ на определённые события, связанные с таблицей. Этими событиями обычно являются операции модификации данных: INSERT, UPDATE или DELETE.
Триггеры могут срабатывать до (BEFORE) или после (AFTER) выполнения события.
Основные сценарии использования:
-
Аудит и логирование: Автоматическая запись информации о том, кто, когда и какие данные изменил, в отдельную таблицу логов. Пример: при каждом обновлении зарплаты сотрудника сохранять старое значение, новое значение и имя пользователя, выполнившего операцию.
-
Поддержание целостности данных и сложная валидация: Реализация бизнес-правил, которые невозможно описать стандартными ограничениями (
CHECK,FOREIGN KEY). Пример: запретить удаление проекта, если у него еще есть активные задачи. -
Автоматическое вычисление производных данных: Обновление вычисляемых полей в других таблицах. Пример: при добавлении нового товара в заказ автоматически пересчитывать и обновлять поле
total_sumв таблице заказов.
Пример (псевдокод SQL):
CREATE TRIGGER update_order_sum
AFTER INSERT ON order_items
FOR EACH ROW
BEGIN
UPDATE orders
SET total_sum = total_sum + NEW.price
WHERE id = NEW.order_id;
END;Важные риски:
- Скрытая логика: Триггеры делают логику работы с данными неявной. Разработчик может не догадываться об их существовании, что усложняет отладку.
- Производительность: Неправильно написанный триггер может серьезно замедлить операции записи в базу данных.
- Сложность: Каскадные триггеры (когда один триггер вызывает другой) могут привести к непредсказуемому поведению и сложным для отладки цепочкам вызовов.
Ответ 18+ 🔞
Ну вот, сидишь ты такой, пишешь в базу, всё по фэншую. INSERT, UPDATE, DELETE — красота. А база тебе в ответ: «Ага, щас, подожди, я тут кое-что своё проверну». И начинается, блядь, магия, о которой ты нихуя не подозревал! Это и есть триггер, ёпта. По сути, это такая пришитая к таблице процедурка, которая врубается автоматом, когда ты лезешь менять данные.
Может врубиться ДО твоей операции (BEFORE) или ПОСЛЕ (AFTER), как ей там в конфиге прописали.
И зачем этот геморрой, спросишь? А вот зачем, хитрая жопа:
-
Шпионить и записывать всё нахуй (аудит). Чтоб потом, когда начальник орёт «КТО БЛЯДЬ ЗАПИСАЛ В МОЮ ТАБЛИЦУ?!», можно было тыкнуть пальцем в лог. Пример: кто-то повысил себе зарплату в 100 раз — триггер тут же сохранит в отдельную табличку: «Вася Пупкин, такого-то числа, было 100, стало 1000000. Пидарас шерстяной».
-
Умничать и запрещать то, что нельзя. Бывают правила посложнее, чем «это поле не пустое». Например, нельзя удалять отдел, пока в нём хоть один работник числится. Ограничениями (
FOREIGN KEY) тут не всегда выкрутишься. А триггер — запросто проверит и скажет: «Не, мудак, сначала людей уволь». -
Автоматически считать всякую хуйню. Чтоб тебе, тупому, не приходилось каждый раз вручную пересчитывать итоги. Добавил строчку в заказ — триггер тут же долбанул по таблице заказов и прибавил сумму. Красота, блядь!
Вот тебе пример, как это выглядит под капотом:
CREATE TRIGGER update_order_sum
AFTER INSERT ON order_items
FOR EACH ROW
BEGIN
UPDATE orders
SET total_sum = total_sum + NEW.price
WHERE id = NEW.order_id;
END;НО! Тут и собака зарыта, сука. Риски, блядь:
- Логика-невидимка. Самый пиздец. Ты пишешь простой
UPDATE, а у тебя полбазы пересчитывается, логи пишутся и ещё ёжиков где-то запускают. И ты об этом ни хуя не знаешь! Отлаживать — просто волнение ебать, пока не поймёшь, откуда ноги растут. - Тормоза. Накосячишь с триггером — и каждая твоя запись будет выполняться как будто через жопу слона. Овердохуища времени уйдёт.
- Цепная реакция. Один триггер дернул другую таблицу, в той свой триггер встал колом и пошёл дергать третью... И всё, пизда, накрылся медным тазом, разобраться, кто кого ебнул, почти невозможно.