Триггеры базы данных

Question

В прошлом я никогда не был фанатом использования триггеров для таблиц базы данных. Для меня они всегда представляли некоторую «магию», которая должна была произойти на стороне базы данных, далеко от контроля кода моего приложения. Я также хотел ограничить объем работы, которую должна выполнять БД, поскольку это обычно общий ресурс, и я всегда предполагал, что триггеры могут дорого обойтись в сценариях с высокой нагрузкой.

Тем не менее я обнаружил пару случаев, когда триггеры имели смысл использовать (по крайней мере, на мой взгляд, они имели смысл). Однако недавно я оказался в ситуации, когда мне иногда нужно было «обходить» курок. Я чувствовал себя виноватым из-за необходимости искать способы сделать это, и я все еще думаю, что лучший дизайн базы данных уменьшит необходимость в этом обходе. К сожалению, эта БД используется множеством приложений, некоторые из которых обслуживаются очень некомпетентной командой разработчиков, которая кричала об изменениях схемы, поэтому я застрял.

Каково общее мнение о триггерах? Любишь их? Ненавижу их? Думаешь, они служат цели в некоторых сценариях? Думаете ли вы, что необходимость обходить триггер означает, что вы «делаете это неправильно»?

Answer 1

Я впервые использовал триггеры пару недель назад. Мы перешли с производственного сервера с SQL 2000 на SQL 2005 и обнаружили, что драйверы ведут себя по-разному с полями NText (для хранения большого XML-документа), отбрасывая последний байт. Я использовал триггер как временное исправление, чтобы добавить дополнительный фиктивный байт (пробел) в конец данных, решая нашу проблему до тех пор, пока не будет найдено правильное решение.

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

Answer 2

Лично я не фанат. Я буду их использовать, но только тогда, когда обнаружу узкое место в коде, которое можно устранить, переместив действия в триггер. Как правило, я предпочитаю простоту, и один из способов сохранить простоту - хранить логику в одном месте - приложении. Я также работал на рабочих местах, где доступ очень ограничен. В этих средах, чем больше кода я заполняю, тем больше людей приходится привлекать даже для самых простых исправлений.