Целесообразно ли использовать триггер для обновления другой таблицы?

8

У меня есть Objectтаблица, которая заполняется из интегрированной службы ( которую я могу изменить при необходимости ) из другой базы данных. В определенные моменты нам нужно вручную добавлять записи в другую таблицу, ObjectObjectGroup (ObjectId, ObjectGroupId)которая необходима, если они Object.ObjectTypeимеют определенное целочисленное значение. Поскольку служба интеграции не обрабатывает такого рода обновления, я подумываю добавить триггер к таблице объектов, который в псевдокоде будет следующим:

if Object.ObjectType = 10
    begin
        if Object.ObjectNumber like '<string pattern>'
        begin
            insert into ObjectObjectGroup values...
        end
    end

Это мудрая настройка или есть лучший способ с точки зрения производительности?

sql-server trigger

— Бенни Скогберг
источник

9

В основном копирование / вставка моего ответа на этот вопрос на stackoverflow

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

Некоторые вещи, которые я бы по-прежнему использовал для запуска

Отслеживание полей "date_created" и "date_last_edited"
Вставка идентификаторов (в оракуле, где нет поля автоматического идентификатора)
Ведение истории изменений

Вещи, которые вы не хотели бы использовать триггеры для

бизнес-правила / логика
все, что подключается за пределами базы данных (например, вызов веб-службы)
Контроль доступа
Все, что не является транзакционным (все, что вы делаете в триггере, ДОЛЖНО иметь возможность отката с транзакцией)

— Мэтью Уотсон
источник

4

Да, это мудро. Это фактически цель триггера, чтобы выполнить необходимые действия после операции вставки / обновления / удаления таблицы.

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

— Мэриан
источник

1

Пока служба, которая заполняет базу данных, не делает всего, что нужно человеку, и до тех пор, пока он не может изменить службу (это мое мнение после описания), и вопрос здесь в DBA.SE, а не в программистах. Я скажу, что хорошо задокументированный триггер не должен быть проблемой. Он сказал, что он делает некоторые вещи вручную, поэтому изменение кода не может быть связано с тем, что я понимаю ..

— Marian

1

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

— Мэтью Уотсон

кашель . Я вижу, куда это идет. Извините за непонятность в моем вопросе выше. У меня есть возможность изменить сервис интеграции, даже если он не принадлежит мне. Из того, что я могу прочитать, лучше изменить службу интеграции и использовать только триггеры для служб аудита / записи истории.

— Бенни Скогберг

3

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

Когда вы делаете ошибку в триггере, все может ДРАСТИЧЕСКИ ошибаться, и если вы не выполняете трассировку, вы не поймете ...
Они «волшебным образом» изменяют / вставляют / удаляют данные, которые пользователь БД (текущее приложение / любое будущее приложение / разработчик, выполняющий одноразовое обновление) не осознал / намеревался.

Большая проблема заключается в том, что после того, как вы создали триггер, другим разработчикам / пользователям не очевидно, что триггер есть и что он делает.

Тем не менее, они являются отличным инструментом для поддержания целостности ваших данных и для истинного аудита изменений.

Вы должны спросить себя, подходит ли логика, которую вы хотите поместить в триггер, лучше всего с приложениями или внутри БД, взвесив риски с обеих сторон (что происходит, если новое приложение появляется и не применяет это править?)

— Эндрю Бикертон
источник