Re[2]: Порядок срабатывания ограничений сылочной целостности

[Sergey Mereutsa]

Привет!

>> системный триггер сработает раньше - тот, что на таблице "В" или тот,
>> что на таблице "Б"?

> возможно, в порядке (прямом или обратном) создания триггеров, который не
> обязательно совпадает с порядком создания таблиц (но вероятно совпадает с
> порядком создания constraint foreign key)

> можешь через post message "trigger-name + timestamp" или  insert into log
> values (t-n, ts) поиграться с разными порядками создания FK-триггеров и
> посмотреть зависят ли ?

Да эт понятно, что могу, но меня интересует, регламентируется ли это
как-то вообще?


> PS: а зачем ? м.б. нужные действия вытащить в триггер В.BeforeDelete и
> плевать в каком порядке будут вызываться и кто первым будет удалять?

Из любопытства. Триггер - это решение, но мне интересно, как себя
должны вести системные триггеры и регламентируется ли их поведение. :)



-- 
Best regards,
 Sergeymailto:gebele...@gmail.com

Re: Re[2]: Порядок срабатывания ограничений сылочной целостности

[Arioch]

В письме от Wed, 06 Apr 2011 12:28:07 +0400, Sergey Mereutsa  
 сообщал:



Из любопытства. Триггер - это решение, но мне интересно, как себя
должны вести системные триггеры и регламентируется ли их поведение. :)


а зачем ?

системный сводится к deete from Table1 where condition1

удалит он одну уникальную строку, 100 или ноль - какая ему разница ?
нет там строк, потому что их и не было, или потому что раньшще отработал  
другой триггер - какая разница ?


разве что рекурсию не плодить и удалять из B одним прямым delete'ом, а не  
10 отдельными delete'ами приехавшими из Б


но большая ли разница, ведь те 10 все равно вызовутся в итоге, и все равно  
проведут свой поиск.


--
Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/