powered by simpleCommunicator - 2.0.59     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Trigger call reason
13 сообщений из 13, страница 1 из 1
Trigger call reason
    #32020093
Shatl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Hi!
Есть триггер на INSERT, UPDATE и DELETE.
Каким образом определить внутри триггера операцию, которая привела е его вызову (кроме анализа содержимого таблиц inserted и deleted или создания отдельных триггеров)?
...
Рейтинг: 0 / 0
Trigger call reason
    #32020110
Только по количеству записей в inserted и deleted.
...
Рейтинг: 0 / 0
Trigger call reason
    #32020112
QWERTY
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
CREATE TRIGGER ins ON dbo.tabl
FOR insert
AS
insert into tabl1 (pole1,operation)
select pole1,'ins' from inserted

CREATE TRIGGER del ON dbo.tabl
FOR DELETE
AS
insert into tabl1 (pole1,operation)
select pole1,'del ' from deleted

в tabl1 получаем записи, которые были вставлены или удалены, или определяем константу и передаем ее куда-нить
поправьте если что.
...
Рейтинг: 0 / 0
Trigger call reason
    #32020114
MadDog
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Shatl:

1. Зачем один триггер, когда лучше три? "Разделяй и властвуй!".
Триггеры, как мне кажется, были созданы для реализации сложной бизнес логики. А один триггер вместо трех - это, обычно, как раз в три раза сложнее.


2. Если условие where не удовлетворяет ни одной записи (например: 1=0), то таблицы inserted и deleted обе будут пустыми. Т.е., каким образом был вызван триггер, определить будет невозможно.
...
Рейтинг: 0 / 0
Trigger call reason
    #32020116
MadDog
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Shatl:

3. Еще забыл - в смешанном insert/update триггере тяжело будет пользоваться функцией update().
...
Рейтинг: 0 / 0
Trigger call reason
    #32020122
> Триггеры, как мне кажется, были созданы для реализации сложной бизнес логики. А один триггер вместо трех - это, обычно, как раз в три раза сложнее.

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

> Если условие where не удовлетворяет ни одной записи (например: 1=0), то таблицы inserted и deleted обе будут пустыми. Т.е., каким образом был вызван триггер, определить будет невозможно.

Человека не интересует, каким образом был вызван триггер, а интересует какая операция ПРОИЗОШЛА. Улавливаешь разницу. Если в inserted и в deleted нету записей, то никакой фактической операции не произошло, хотя конечно триггер был вызван. Это четвертый случай, требующий отдельной обработки.

> в смешанном insert/update триггере тяжело будет пользоваться функцией update().

Верное замечание. Но, очень часто функцией update() тяжело пользоваться даже при операции UPDATE (кто попадал, меня поймет). Так что потеря функциональности невелика, можно и поступиться.
...
Рейтинг: 0 / 0
Trigger call reason
    #32020129
GreenSunrise
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Насчет кода, который должен выполняться в любом случае, Глеб прав. Ситуация довольно частая. Но и наращивание кода триггера типа снежной бабы, тоже выход не самый лучший. Если есть возможность, стОит попробовать этот общий код выделить в функцию или процедуру. Если это возможно, то все проблемы отвалятся сами собой - три триггера вместо одного, и вызов этой функции в триггерах на insert и update.
Shatl, этот способ реализуем в вашем случае?
...
Рейтинг: 0 / 0
Trigger call reason
    #32020130
MadDog
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
г-ну Уфимцеву:
Да понимаю я все это. И разницу "могу почувствовать".


Просто привел еще одно, другое, мнение. Опытом поделился.

Судя по всему, Shatl не совсем "чайник", раз знает про таблицы inserted и deleted.
Соответственно, куда ему девать "нехилого размера код", он сам сообразит, может процедурку оформит (или две), может функцию (и даже не одну), а может все в триггере оставит. Дело вкуса. Кто как научен.

Что же касается пустых таблиц inserted и deleted, то это достаточно распространенные грабли даже при написании простых триггеров. Не говоря уже о смешанных. Хотя, конечно, можно воспользоваться @@ROWCOUNT.

А про функцию update() напомнил на всякий случай. Не сразу можно сообразить что она срабатывает в insert триггере тоже. Хотя Вы правы, можно и без нее.

Просто мнение.
...
Рейтинг: 0 / 0
Trigger call reason
    #32020142
Shatl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
2 GreenSunrise:
На данный момент я остановился на анализе кол-ва записей в inserted и deleted.
На счет нескольких тригеров -- не очень удобно т.к. такие вещи прийдется вешать не на 1..2 таблицы, а штук на 10..20 (с разной структурой) и сопровождать это дело потом будет не очень весело.

P.S. Кто чего использует для синхронизации метаданных между двумя базами (тестовая и боевая)?
...
Рейтинг: 0 / 0
Trigger call reason
    #32020179
BiSas
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
У меня тоже есть небольшое замечание. Общий код оформить процедурой, не всегда получается, потому что в этой процедуре ты уже не получишь доступа к inserted и deleted. А копировать эти таблички во временные, я думаю производительности не прибавит. К тому же если я не путаю при использовании временных таблиц, триггер будет все время перекомпилироваться, что тоже минус к производительности. Поэтому мне кажеться, что лучше делать несколько триггеров. Общую часть помещать в триггер, который срабатывает на все события, а остальное если надо можно разделять. Такое невозможно сделать только в SQL 6.5. А в 2000 еще возможностей добавилось, например можно указать какой триггер должен сработать первым.
Насчет Update() мне тоже не совсем нравится как он работает. Например, то что срабатывание Update() вовсе не означает, что данные были изменены, а только то, что это поле было указанно в предложении Update.
...
Рейтинг: 0 / 0
Trigger call reason
    #32020185
GreenSunrise
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2BiSas: если "общая" часть кода и "персональная" НЕ ЗАВИСЯТ друг от друга, то это замечательно. То есть их логика самодостаточна и порядок срабатывания триггеров неважен. Потому что MS не гарантирует нужного вам порядка срабатывания триггеров. Влиять на это можно некоторыми способами (давайте не будем их тут обсуждать, тем более что довольно давно на форуме такая тема поднималась), но закладываться на это нельзя.
Но imho в данной ситуации выделить независимые куски кода будет почти невозможно. Это судя по тому, что человек не считает возможным (или нужным) сделать процедуру, которая будет вызываться из триггера, и запихать кусок кода туда.
...
Рейтинг: 0 / 0
Trigger call reason
    #32020196
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Вдруг кто не знает (я например только сегодня прочитал)

sp_settriggerorder
Specifies which AFTER triggers associated with a table will be fired first or last. The AFTER triggers that will be fired between the first and last triggers will be executed in undefined order.

ну и далее по хелпу
...
Рейтинг: 0 / 0
Trigger call reason
    #32020200
GreenSunrise
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Это фишка известная. Не помню, была ли она в семерке, но в 2000 я ее давно и вполне успешно юзаю. Но, кажется, тут речь идет о более общей проблеме. В системе со сложной логикой, реализованной на триггерах, места как первого, так и последнего триггера могут быть давно заняты по различным причинам.
...
Рейтинг: 0 / 0
13 сообщений из 13, страница 1 из 1
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Trigger call reason
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]