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

Question

Предположим, у меня есть хранимые процедуры, которые выполняют операции вставки / обновления / удаления таблицы.

В зависимости от некоторых критериев, я хочу выполнить некоторые операции.

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

Уменьшает ли использование триггеров производительность?

Существуют ли эти две таблицы, а именно: Вставлено и Удалено , существует (постоянно) или создается динамически?

Если они создаются динамически, это имеет проблемы с производительностью.

Если они являются постоянными таблицами, то где они?

Также, если они exixts, тогда я могу получить доступ к Вставленные и Удаленные таблицы в хранимых процедурах?

Answer 1

Будет ли это менее производительным, чем делать то же самое в хранимых процессах. Вероятно, нет, но со всеми вопросами производительности единственный способ действительно знать, это проверить оба подхода с реалистичным набором данных (если у вас есть таблица с 2 000 000 записей, не тестируйте с таблицей с 100 записями!)

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

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

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

Answer 2

Да, таблица с триггером не будет работать так же, как без него. Логика подсказывает, что делать что-то дороже, чем ничего не делать.

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

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

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

Answer 3

Снижает производительность запроса по определению: тогда запрос выполняет то, что в противном случае он не собирался делать.

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

Сделайте еще один шаг: это преимущество исчезнет, ​​если вы используете хранимую процедуру и в любом случае выполняете в пределах одного и того же сервера.

Так что это зависит от того, как вы на это смотрите.

Answer 4

Производительность на чем? триггер выполнит обновление базы данных после события, поэтому пользователь вашей системы даже не узнает, что это происходит. Это происходит на заднем плане.

Ваш вопрос сформулирован довольно сложно для понимания.