Несколько дней назад мы разбирали, почему...

Типовые случаи применения триггеров: Автоматический журнал изменений: кто, когда и что поменял в важной таблице Проверка хитрых условий, которые нельзя задать обычными CHECK или UNIQUE. Например, "нельзя добавить заказ на склад, который закрыт в этот день". Триггер проверит и выдаст ошибку, не дав записать Автозаполнение/пересчёт. Например, при смене цены триггер сам обновляет сумму в связанном счёте, чтобы данные не расходились Маскирование/шифрование. Например, при вставке номера паспорта триггер сам превращает его в хеш Безопасность. Например, запретить удалять таблицы Какие альтернативы нужно обязательно рассмотреть перед тем, как использовать триггеры: ⚖ Прикладной уровень: валидация и бизнес-логика в коде, перед записью ⚖ Хранимые процедуры

Хранимая процедура - это предварительно скомпилированный набор SQL-операторов и процедурной логики (ветвления, циклы), который хранится на сервере БД и вызывается отдельно, по имени. Она может принимать параметры и возвращать результаты. Дает преимущество в производительности, отладке и безопасности (закрывая прямой доступ к таблицам)

⚖ Представления (view) с правилами ⚖ Констрейнты (PK, FK, UNIQUE, CHECK, EXCLUDE): они быстрее, предсказуемее, параллельнее Если без триггера не обойтись: Триггеры должны использоваться строго для контроля целостности данных (например, в кейсе, когда сумма долей не должна превышать 1, или нужна проверка на пересекающиеся интервалы дат) Триггер не должен менять данные, иначе сразу появляются долгие блокировки и deadlock'и Триггер не должен управлять транзакцией: такую логику невозможно отладить Обязательно ведите в документации общий граф вызовов триггеров, чтобы не получить сюрприз на проде под большой нагрузкой