Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Trigger call reason
|
|||
|---|---|---|---|
|
#18+
Hi! Есть триггер на INSERT, UPDATE и DELETE. Каким образом определить внутри триггера операцию, которая привела е его вызову (кроме анализа содержимого таблиц inserted и deleted или создания отдельных триггеров)? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.01.2002, 10:34 |
|
||
|
Trigger call reason
|
|||
|---|---|---|---|
|
#18+
Только по количеству записей в inserted и deleted. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.01.2002, 07:15 |
|
||
|
Trigger call reason
|
|||
|---|---|---|---|
|
#18+
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 получаем записи, которые были вставлены или удалены, или определяем константу и передаем ее куда-нить поправьте если что. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.01.2002, 07:22 |
|
||
|
Trigger call reason
|
|||
|---|---|---|---|
|
#18+
2 Shatl: 1. Зачем один триггер, когда лучше три? "Разделяй и властвуй!". Триггеры, как мне кажется, были созданы для реализации сложной бизнес логики. А один триггер вместо трех - это, обычно, как раз в три раза сложнее. 2. Если условие where не удовлетворяет ни одной записи (например: 1=0), то таблицы inserted и deleted обе будут пустыми. Т.е., каким образом был вызван триггер, определить будет невозможно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.01.2002, 08:05 |
|
||
|
Trigger call reason
|
|||
|---|---|---|---|
|
#18+
2 Shatl: 3. Еще забыл - в смешанном insert/update триггере тяжело будет пользоваться функцией update(). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.01.2002, 08:26 |
|
||
|
Trigger call reason
|
|||
|---|---|---|---|
|
#18+
> Триггеры, как мне кажется, были созданы для реализации сложной бизнес логики. А один триггер вместо трех - это, обычно, как раз в три раза сложнее. А если есть нехилого размера код, который должен выполняться во всех случаях? В таком случае единый триггер - удобно, а чтобы выполнить часть кода уникального для разного типа операций, то используется определение типа операции. > Если условие where не удовлетворяет ни одной записи (например: 1=0), то таблицы inserted и deleted обе будут пустыми. Т.е., каким образом был вызван триггер, определить будет невозможно. Человека не интересует, каким образом был вызван триггер, а интересует какая операция ПРОИЗОШЛА. Улавливаешь разницу. Если в inserted и в deleted нету записей, то никакой фактической операции не произошло, хотя конечно триггер был вызван. Это четвертый случай, требующий отдельной обработки. > в смешанном insert/update триггере тяжело будет пользоваться функцией update(). Верное замечание. Но, очень часто функцией update() тяжело пользоваться даже при операции UPDATE (кто попадал, меня поймет). Так что потеря функциональности невелика, можно и поступиться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.01.2002, 08:51 |
|
||
|
Trigger call reason
|
|||
|---|---|---|---|
|
#18+
Насчет кода, который должен выполняться в любом случае, Глеб прав. Ситуация довольно частая. Но и наращивание кода триггера типа снежной бабы, тоже выход не самый лучший. Если есть возможность, стОит попробовать этот общий код выделить в функцию или процедуру. Если это возможно, то все проблемы отвалятся сами собой - три триггера вместо одного, и вызов этой функции в триггерах на insert и update. Shatl, этот способ реализуем в вашем случае? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.01.2002, 09:18 |
|
||
|
Trigger call reason
|
|||
|---|---|---|---|
|
#18+
г-ну Уфимцеву: Да понимаю я все это. И разницу "могу почувствовать". Просто привел еще одно, другое, мнение. Опытом поделился. Судя по всему, Shatl не совсем "чайник", раз знает про таблицы inserted и deleted. Соответственно, куда ему девать "нехилого размера код", он сам сообразит, может процедурку оформит (или две), может функцию (и даже не одну), а может все в триггере оставит. Дело вкуса. Кто как научен. Что же касается пустых таблиц inserted и deleted, то это достаточно распространенные грабли даже при написании простых триггеров. Не говоря уже о смешанных. Хотя, конечно, можно воспользоваться @@ROWCOUNT. А про функцию update() напомнил на всякий случай. Не сразу можно сообразить что она срабатывает в insert триггере тоже. Хотя Вы правы, можно и без нее. Просто мнение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.01.2002, 09:24 |
|
||
|
Trigger call reason
|
|||
|---|---|---|---|
|
#18+
2 GreenSunrise: На данный момент я остановился на анализе кол-ва записей в inserted и deleted. На счет нескольких тригеров -- не очень удобно т.к. такие вещи прийдется вешать не на 1..2 таблицы, а штук на 10..20 (с разной структурой) и сопровождать это дело потом будет не очень весело. P.S. Кто чего использует для синхронизации метаданных между двумя базами (тестовая и боевая)? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.01.2002, 11:42 |
|
||
|
Trigger call reason
|
|||
|---|---|---|---|
|
#18+
У меня тоже есть небольшое замечание. Общий код оформить процедурой, не всегда получается, потому что в этой процедуре ты уже не получишь доступа к inserted и deleted. А копировать эти таблички во временные, я думаю производительности не прибавит. К тому же если я не путаю при использовании временных таблиц, триггер будет все время перекомпилироваться, что тоже минус к производительности. Поэтому мне кажеться, что лучше делать несколько триггеров. Общую часть помещать в триггер, который срабатывает на все события, а остальное если надо можно разделять. Такое невозможно сделать только в SQL 6.5. А в 2000 еще возможностей добавилось, например можно указать какой триггер должен сработать первым. Насчет Update() мне тоже не совсем нравится как он работает. Например, то что срабатывание Update() вовсе не означает, что данные были изменены, а только то, что это поле было указанно в предложении Update. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.01.2002, 05:30 |
|
||
|
Trigger call reason
|
|||
|---|---|---|---|
|
#18+
2BiSas: если "общая" часть кода и "персональная" НЕ ЗАВИСЯТ друг от друга, то это замечательно. То есть их логика самодостаточна и порядок срабатывания триггеров неважен. Потому что MS не гарантирует нужного вам порядка срабатывания триггеров. Влиять на это можно некоторыми способами (давайте не будем их тут обсуждать, тем более что довольно давно на форуме такая тема поднималась), но закладываться на это нельзя. Но imho в данной ситуации выделить независимые куски кода будет почти невозможно. Это судя по тому, что человек не считает возможным (или нужным) сделать процедуру, которая будет вызываться из триггера, и запихать кусок кода туда. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.01.2002, 06:52 |
|
||
|
Trigger call reason
|
|||
|---|---|---|---|
|
#18+
Вдруг кто не знает (я например только сегодня прочитал) 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. ну и далее по хелпу ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.01.2002, 14:34 |
|
||
|
Trigger call reason
|
|||
|---|---|---|---|
|
#18+
Это фишка известная. Не помню, была ли она в семерке, но в 2000 я ее давно и вполне успешно юзаю. Но, кажется, тут речь идет о более общей проблеме. В системе со сложной логикой, реализованной на триггерах, места как первого, так и последнего триггера могут быть давно заняты по различным причинам. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.01.2002, 14:48 |
|
||
|
|

start [/forum/topic.php?fid=46&fpage=3517&tid=1824424]: |
0ms |
get settings: |
6ms |
get forum list: |
16ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
26ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
66ms |
get tp. blocked users: |
2ms |
| others: | 243ms |
| total: | 380ms |

| 0 / 0 |
