Что такое Database Triggers и в каких случаях их использование оправдано для автоматизации бизнес-логики в базе данных?

Database Trigger (триггер базы данных) — это специальный объект базы данных, представляющий собой хранимую процедуру, которая автоматически выполняется в ответ на определённые события: вставку (INSERT), обновление (UPDATE) или удаление (DELETE) данных в таблице. В некоторых СУБД триггеры также могут срабатывать на DDL-события (CREATE, ALTER, DROP) или системные события.

**Как работают триггеры?**

Триггер привязывается к конкретной таблице и событию. Он может срабатывать:
— **BEFORE** — до выполнения операции (позволяет изменить или отклонить данные);
— **AFTER** — после выполнения операции (подходит для логирования, обновления связанных таблиц);
— **INSTEAD OF** — вместо операции (используется преимущественно для представлений/views).

Внутри триггера доступны псевдотаблицы NEW и OLD (или INSERTED/DELETED в SQL Server), содержащие новые и старые значения строк.

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

1. **Аудит и логирование изменений.** Триггер автоматически записывает историю изменений в отдельную таблицу-лог, гарантируя, что ни одно изменение не будет пропущено, независимо от источника запроса.

2. **Поддержание целостности данных.** Когда ограничения CHECK и FOREIGN KEY недостаточны, триггер позволяет реализовать сложные бизнес-правила — например, запрет снижения цены товара ниже себестоимости.

3. **Каскадные обновления денормализованных данных.** Если в базе хранятся агрегированные или денормализованные данные (например, счётчик заказов в профиле клиента), триггер обеспечивает их актуальность.

4. **Автоматическое заполнение полей.** Генерация значений по умолчанию, которые невозможно задать стандартными средствами: временные метки, UUID, вычисляемые поля.

5. **Репликация и синхронизация данных.** Триггеры используются для отслеживания изменений при построении CDC (Change Data Capture) систем.

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

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

**Поддержка в популярных СУБД:**
— PostgreSQL, MySQL, Oracle, SQL Server, SQLite — все поддерживают триггеры с незначительными синтаксическими различиями.

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