Триггеры: BEFORE, AFTER, INSTEAD OF — автоматические действия

Что такое триггеры и зачем они нужны? 🔥

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

Главные суперсилы триггеров:

• Автоматизация рутинных операций
• Контроль целостности данных
• Логирование изменений
• Реализация сложных бизнес-правил

Виды триггеров по времени срабатывания ⏱️

Триггеры различаются по моменту выполнения относительно основного запроса:

BEFORE — страж на входе 🛡️

Срабатывает перед выполнением основного запроса. Идеален для:

• Проверки и валидации данных
• Модификации данных перед сохранением
• Предотвращения нежелательных изменений

CREATE TRIGGER validate_email_before_insert
BEFORE INSERT ON users
FOR EACH ROW
BEGIN
    IF NEW.email NOT LIKE '%@%.%' THEN
        SIGNAL SQLSTATE '45000' 
        SET MESSAGE_TEXT = 'Invalid email format!';
    END IF;
END;

AFTER — внимательный архивариус 📚

Срабатывает после выполнения основного запроса. Отлично подходит для:

• Логирования изменений
• Обновления агрегированных данных
• Синхронизации связанных таблиц

CREATE TRIGGER log_user_changes
AFTER UPDATE ON users
FOR EACH ROW
BEGIN
    INSERT INTO audit_log (user_id, changed_field, old_value, new_value, change_date)
    VALUES (OLD.id, 'email', OLD.email, NEW.email, NOW());
END;

INSTEAD OF — хитрый перехватчик 🎭

Срабатывает вместо основного запроса (особенно полезен для представлений). Позволяет:

• Реализовать сложную логику обновления представлений
• Перенаправлять операции на другие таблицы
• Обрабатывать "необновляемые" представления

CREATE TRIGGER update_complex_view
INSTEAD OF UPDATE ON user_order_view
FOR EACH ROW
BEGIN
    UPDATE users SET name = NEW.user_name WHERE id = NEW.user_id;
    UPDATE orders SET status = NEW.order_status WHERE id = NEW.order_id;
END;

Жизненный цикл триггера 🔄

1. Событие-инициатор: INSERT, UPDATE или DELETE
2. Момент срабатывания: BEFORE/AFTER/INSTEAD OF
3. Условия (если заданы): WHEN
4. Тело триггера: SQL-операции
5. Результат: Возврат управления основному запросу

Практикум: реальные кейсы из жизни 💼

Кейс 1: Автоматический расчет рейтинга

CREATE TRIGGER update_product_rating
AFTER INSERT ON product_reviews
FOR EACH ROW
BEGIN
    UPDATE products
    SET rating = (
        SELECT AVG(rating) 
        FROM product_reviews 
        WHERE product_id = NEW.product_id
    )
    WHERE id = NEW.product_id;
END;

Кейс 2: Защита от удаления важных записей

CREATE TRIGGER prevent_critical_delete
BEFORE DELETE ON departments
FOR EACH ROW
BEGIN
    IF OLD.name = 'Management' THEN
        SIGNAL SQLSTATE '45000'
        SET MESSAGE_TEXT = 'Cannot delete Management department!';
    END IF;
END;

Кейс 3: Синхронизация denormalized данных

CREATE TRIGGER sync_order_totals
AFTER INSERT ON order_items
FOR EACH ROW
BEGIN
    UPDATE orders
    SET total_amount = (
        SELECT SUM(price * quantity)
        FROM order_items
        WHERE order_id = NEW.order_id
    )
    WHERE id = NEW.order_id;
END;

Лучшие практики работы с триггерами 🏆

1. Держи триггеры простыми — сложная логика усложняет отладку
2. Избегай рекурсий — триггер, вызывающий сам себя, это катастрофа
3. Тестируй все сценарии — особенно пограничные случаи
4. Документируй назначение — комментарии спасают жизни (разработчиков)
5. Следи за производительностью — медленные триггеры тормозят всю систему

-- Пример хорошо документированного триггера
CREATE TRIGGER maintain_employee_stats
AFTER INSERT ON employees
FOR EACH ROW
/*
 * Цель: Поддерживает актуальность статистики по отделам
 * Автор: Команда HR
 * Дата: 2023-11-15
 */
BEGIN
    -- Обновляем количество сотрудников в отделе
    UPDATE departments
    SET employee_count = employee_count + 1
    WHERE id = NEW.department_id;

    -- Логируем событие найма
    INSERT INTO hiring_log (employee_id, department_id, hire_date)
    VALUES (NEW.id, NEW.department_id, NEW.hire_date);
END;

Опасности и подводные камни ⚠️

1. Невидимые побочные эффекты — изменения могут происходить "за кулисами"
2. Цепные реакции — один триггер может запускать другие
3. Проблемы транзакций — триггеры выполняются в той же транзакции
4. Сложность отладки — ошибки не всегда очевидны
5. Проблемы миграции — триггеры могут усложнять перенос данных

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

✅ Бизнес-правила, которые должны выполняться всегда
✅ Аудит и логирование критических изменений
✅ Поддержание согласованности denormalized данных
✅ Валидация данных на уровне БД

Когда лучше избегать? 🚧

❌ Слишком сложная бизнес-логика
❌ Высоконагруженные системы, где важна производительность
❌ Когда ту же логику можно реализовать на уровне приложения
❌ Для задач, которые можно решить constraints и checks

Проверь себя: мини-викторина 🧠

1. В каком триггере можно отменить операцию до ее выполнения?
2. Какой тип триггера нужен для обновления "необновляемого" представления?
3. Как предотвратить бесконечную рекурсию триггеров?
4. Какой SQL-оператор используется для генерации ошибки в триггере?

Ответы: 1-BEFORE, 2-INSTEAD OF, 3-Контролировать цепочки вызовов, 4-SIGNAL SQLSTATE