Причины возражений против триггеров SQL, которые вставляют данные в другие таблицы?

Question

Мне сказал человек с некоторыми полномочиями в нашей компании, что это «база данных нет-нет» для создания триггеров в базе данных, которые изменяют строки в другой таблице.

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

Таким образом, мой измеритель уровня BS привязан к этому.Я что-то упускаю из-за этой техники, что делает ее плохой практикой вообще?

Answer 1

Если вы осторожны с кодом триггера, в этом нет ничего плохого.Некоторые люди получают укус плохого триггерного кода, а затем решают, что триггеры плохие (хотя проблема была в плохом триггерном коде).Затем они обобщают это как «никогда не использовать триггеры».

Другая проблема заключается в том, что ....

Используя таблицы аудита в качестве примера, предположим, что у вас есть хранимая процедура, которая обновляет таблицуИ помещает данные в таблицу аудита.Теперь предположим, что вы пишете код триггера для помещения данных в таблицу аудита.Вы можете получить дубликаты данных аудита.

Answer 2

Я все еще ищу ту книгу, в которой определена «лучшая практика» - думаю, я найду ее рядом с «Большой книгой базы данных no-nos».

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

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

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

Answer 3

Не все триггеры, которые вставляют строки в другую таблицу, являются плохими, например, триггер, который, как вы говорите, сохраняет предыдущую версию строки в таблице AUDIT.Но, не зная подробностей, я подозреваю, что ваша «начальная конфигурация по умолчанию», созданная с помощью триггера, может быть лучше выполнена в хранимой процедуре, потому что SP более самодокументируемый.избегать - и под «своеобразной» я имею в виду идею одного человека о кратчайшем пути, который обходит проверенный и стандартный способ сделать что-то.Они затрудняют текущее обслуживание и могут стать ловушкой для неосторожного программиста, который случится позже.

Answer 4

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

Мой опыт в основном в SQL Server.В старых версиях не было отслеживания изменений или каскадной ссылочной целостности, поэтому вам, возможно, пришлось написать триггеры для самостоятельного ведения журналов и управления ссылочной целостностью в старые добрые времена.Теперь есть превосходные инструменты для обеих этих функций, которые встроены прямо в платформу.Они «чище», чем триггеры, загруженные DML, но все же позволяют вам сохранять эти функции централизованными.

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

Answer 5

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

Так что я бы не назвал это "нет-нет" как таковым, но что-то должно быть сделано с осторожностью.

Answer 6

Это личное предпочтение. На мой взгляд, это плохая практика. Управлять БД, имеющей триггеры для таблиц, обновляющих другие таблицы, может быть немного неоправданно, что вызывает другой триггер для обновления другой таблицы и т. Д.

Для меня имеет больше смысла объединить все функции в хранимую процедуру, чтобы вся логика была в одном месте.

Впрочем, каждому свое.