Триггеры уменьшает производительность? Вставленные и удаленные таблицы?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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