Вернитесь рано из триггера, чтобы пропустить логику - PullRequest
0 голосов
/ 30 сентября 2019

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

Таблица inserted может иметь несколько строк, когда она будет иметь несколько строк? Поскольку триггер срабатывает при обновлении, не будет ли вызываться триггер для каждой строки в обновлении?

Правильно ли использовать приведенный ниже SQL, чтобы игнорировать триггер. Если идентификатор меньше 123, я хочу, чтобы триггер просто RETURN и пропустил логику, которую он обычно делает:

DECLARE @UserID AS INT = (SELECT UserID FROM Inserted)
IF @UserID <= 123
BEGIN
    RETURN
END

Ответы [ 2 ]

2 голосов
/ 30 сентября 2019

SQL Server срабатывает срабатывает один раз за оператор, а не один раз за строку. И оператор может влиять на любое количество строк.

Таким образом, вам придется выполнить свою обычную логику триггера и просто не предпринимать никаких действий для любых строк, которые имеют UserId <= 123.

1 голос
/ 30 сентября 2019

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

if exists (select 1 from Inserted where UserId <= 123) return;

Это потенциально очень опасно, потому что если когда-либо произойдетсмешанное обновление, содержащее как UserId <= 123, так и UserId> 123, триггер не будет работать для этих> 123. И учтите, что, хотя ваше приложение может этого никогда не сделать, администратор баз данных из SSMS может вручную исправить некоторые данные.

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

declare @Id int, @UserId int;
declare @Rows table (Id int, UserId int);

insert into @Rows (Id, UserId)
  select Id, UserId from Inserted;

while exists (select 1 from @Rows) begin
  select top 1 @Id = Id, @UserId = UserId from @Rows;
  if @UserId > 123 begin
    -- Do stuff
  end
  delete from @Rows where Id = @Id;
end

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

...