Я думаю, что они в порядке, когда они используются для заполнения отдельного, одноразового набора таблиц для таких вещей, как протоколирование, агрегация и т.д. для безопасности или создания метаданных, например.
Когда вы начинаете изменять ваши "живые" данные или "возвращаться" в ваши информационные таблицы, вот тогда они становятся злыми и громоздкими. Они также совершенно не нужны для этого. Триггер не может сделать ничего такого, чего не может сделать хранимая процедура.
Мне кажется, что они являются злым эквивалентом GOTOs в языках программирования. Законны, но их следует избегать, если нет крайней необходимости, а они НИКОГДА не являются крайней необходимостью.
Вот несколько статей, которые помогут вам разобраться в своих потребностях самостоятельно.
Короче говоря, Триггеры
полезны для обработки большого количества данных, когда необходимо выполнить сложный DML. Чтобы ответить на ваш вопрос, если это не так, вы получили свой ответ, когда триггер неисправен.
Триггеры базы данных плохи, когда они используются, когда другие функции более уместны.
Функции, которые следует рассмотреть, прежде чем пытаться использовать триггеры:
Контрольные ограничения
Ограничения внешнего ключа
Уникальные индексы/ограничения
(Персистентные) вычисляемые столбцы
(Индексированные) представления (если триггер пытается обновить, например, агрегат)
Хранимые процедуры (если прямой доступ к таблице может быть запрещен)
После этого триггеры могут быть использованы должным образом, не будучи "плохими". Триггеры всегда должны быть спроектированы так, чтобы иметь небольшую площадь.
Потому что они «волшебные». Они не очень заметны и могут делать много работы.
Я видел, как хорошие разработчики тратят много времени, пытаясь отследить проблемы, связанные с триггерами, потому что они просто не думали их искать. К тому же они очень редко нужны.