Перейти на PRO

Что такое триггер в базах данных?

Тип вопроса: Базы данных и SQL Вероятность: 10% Категория: QA Тестировщик

Ответ

Триггер (Trigger) — это специальный хранимый блок кода в СУБД, который автоматически выполняется при наступлении определённого события с таблицей: INSERT, UPDATE или DELETE. Триггер может срабатывать BEFORE (до) или AFTER (после) операции.

Основное назначение:

  • Обеспечение целостности данных и сложных бизнес-правил.
  • Ведение журнала аудита (логирования изменений).
  • Каскадные обновления или вычисления производных данных.

Пример триггера для аудита в PostgreSQL:

CREATE TRIGGER audit_employee_update
AFTER UPDATE ON employees
FOR EACH ROW
EXECUTE FUNCTION log_employee_change();

-- Связанная функция
CREATE OR REPLACE FUNCTION log_employee_change()
RETURNS TRIGGER AS $$
BEGIN
    INSERT INTO employee_audit (
        employee_id,
        changed_at,
        old_salary,
        new_salary
    ) VALUES (
        OLD.id,
        NOW(),
        OLD.salary,
        NEW.salary
    );
    RETURN NEW;
END;
$$ LANGUAGE plpgsql;

Важные аспекты:

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

Ответ 18+ 🔞

А, триггеры, ёпта! Ну это ж такая штука, которая в базе данных сидит, как хитрая жопа, и ждёт своего часа. Представь себе сторожа-невидимку, который автоматически, блядь, впендюривается в твою операцию с таблицей — INSERT, UPDATE или DELETE. И делает это либо до, либо после неё. Сам, сука! Без твоего ведома!

Зачем это, спрашивается, надо?

  • Чтобы целостность данных соблюсти, когда бизнес-правила такие, что просто PRIMARY KEY не хватит, овердохуища логики.
  • Чтобы журнал аудита вести — кто, когда и что поменял. Чтоб потом, если что, было к кому претензии предъявить.
  • Чтобы какие-нибудь каскадные обновления или пересчёты делать.

Вот смотри, как это выглядит в жизни, на примере Постгреса. Допустим, зарплату сотруднику поменяли, а нам надо это в историю записать:

CREATE TRIGGER audit_employee_update
AFTER UPDATE ON employees
FOR EACH ROW
EXECUTE FUNCTION log_employee_change();

-- А это сама функция, которую триггер дергает
CREATE OR REPLACE FUNCTION log_employee_change()
RETURNS TRIGGER AS $$
BEGIN
    INSERT INTO employee_audit (
        employee_id,
        changed_at,
        old_salary,
        new_salary
    ) VALUES (
        OLD.id,    -- Старая запись, блядь!
        NOW(),
        OLD.salary,
        NEW.salary -- А это новая, ебать!
    );
    RETURN NEW;
END;
$$ LANGUAGE plpgsql;

Но тут, чувак, есть подводные, блядь, камни, о которые можно все зубы сломать:

  • Производительность: Каждый раз, когда ты что-то делаешь с таблицей, этот невидимый сторож тоже работу делает. Надо десять тысяч строк обновить? Он десять тысяч раз и выстрелит. Представляешь накладные расходы?
  • Отладка: Ошибка в триггере — это просто пиздец. Потому что выполняется он неявно. Ты UPDATE сделал, а тебе ошибку какую-то непонятную. А это, оказывается, триггер где-то в глубине системы сломался. Волнение ебать!
  • Рекурсия: Вот это вообще, в рот меня чих-пых! Можешь так накрутить, что триггер вызовет операцию, которая снова вызовет этот же триггер. И пошло-поехало, пока сервер не накроется медным тазом. Терпения ноль ебать у админов будет!

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

© ХакСобесов, 2026
support@hacksobesov.com