Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Транзакции в триггере

Страницы: < 1 2 3 4 5 >
sql © (2008-08-29 11:40:00)
ALTER TRIGGER [trgSettings] ON [dbo].[tSettings] AFTER INSERT, DELETE, UPDATE AS BEGIN BEGIN TRANSACTION DECLARE @IdSetting int, @Section nvarchar(32), @Ident nvarchar(32), @Value nvarchar(32), @iDate datetime, @iUser int, @uDate datetime, @uUser int, @Note nvarchar(255), @Now datetime, @i int; SET @Now = GETDATE(); SET NOCOUNT ON; IF EXISTS(SELECT * FROM Inserted) BEGIN IF NOT EXISTS(SELECT * FROM Deleted) BEGIN ROLLBACK TRANSACTION END ELSE BEGIN COMMIT TRANSACTION END; END ELSE BEGIN COMMIT TRANSACTION END; END

В какой части текста триггера лучше всего открывать глобальную, по отношению к триггеру, транзакцию ?

DiamondShark (2008-08-29 13:38:00) [61]

> Транзакции в триггере есть безусловное зло :)

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

DiamondShark (2008-08-29 13:33:00) [62]

> профессионалы стараются избегать триггеров

Профессионалы в какой области? Профессионалы-гинекологи, возможно, и стараются избегать. Профессионалы-программисты СУБД триггеры знают, любят и умеют применять по назначению.

Игорь Шевченко (2008-08-29 13:32:00) [63]
Где б программистов взять...

DiamondShark (2008-08-29 13:28:00) [64]

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

Нет такой "концепции".
Это называется "всю жизнь лабали на фокспро, а потом пацаны сказали, что SQL server типа круто".

MsGuns (2008-08-29 12:54:00) [65]
Следует триггеры воспринимать лишь как дополнительное средство программирования НА СТОРОН СЕРВЕРА и не более того. Дополнительное.
В клиент-серверных системах существует, грубо говоря, две "крайние" концепции построения логики:
чисто клиентская, когда сервер занимается только исполнением запросов от клиента с минимумом "самостоятельности", контроль же за целостностью данных, учет реплик, "сервисные" функции и т.д. остаются на "совести" клиента
и
чисто серверная, когда максимум алгоритмов реализуются самим сервером, клиент же лишь обращается к набору "макро"-функций, зачастую даже не имея представления о физическом представлении данных на сервере и не неся ответственности ни за целостность данных, ни за их полноту и корректность

В каждом конктретном случае применяется собственная "средняя" концепция, заключающаяся в некоей комбинации этих двух концепций. Причем очень часто текущая концепция модели со временем постепенно транформируются от первой крайности ко второй или наоборот. Не зная предметной области и поставленных перед разработчиком СУБД задач, невозможно советовать. Это все равно, что тащить в операционную больного, не удосужившись хотя бы спросить у него, где болит ;)

Palladin (2008-08-29 12:52:00) [66]
из-за ключёв я думаю :)

Игорь Шевченко (2008-08-29 12:49:00) [67]

> А как, по-твоему, устроена операция Update? Сначала Delete,
> потом Insert

а почему не наоборот ?

stas (2008-08-29 12:30:00) [68]
Вверху общие.

Я сразу скажу этот лог (как в примере) работать будет некорректно при пакетной вставке, удалении обновлении.

У нас огранизован лог подобный лог (я не настаиваю на его правильности)
3 триггера на таблицу. Внутри просто
Insert into...
select f1..fn from inserted.
Каждую ночь таблицы LOG списываются в архив и очищаются, т.к. при наполнении таблицы лога вставка происходит все медленее.

sql (2008-08-29 12:25:00) [69]

> stas © (29.08.08 12:23) [15]

А допустим если необходимо при разных событиях иметь общию(ии) переменные...

sql (2008-08-29 12:23:00) [70]

> Ega23 © (29.08.08 12:21) [13]

Не по тексту судить не надо, этот текст к примеру...

stas (2008-08-29 12:23:00) [71]
Ну, или

IF <Условие> --определяем UPDATE
BEGIN
Declare ...
END

IF <Условие> --INSERT
BEGIN
Declare ...
END

IF <Условие> -- DELETE
BEGIN
Declare ...
END
...
Insert into

без всяких транзакций

sql (2008-08-29 12:22:00) [72]

> stas © (29.08.08 12:17) [12]

Мне кажется нет...

Ega23 (2008-08-29 12:21:00) [73]

> т.е. для определения операции?

Ну судя по тексту - да.

stas (2008-08-29 12:17:00) [74]
не проще 3 триггера сделать?

sql (2008-08-29 12:13:00) [75]

> stas © (29.08.08 12:09) [7]

В зависимости от события INSERT, UPDATE, DELETE, делать "разные вещи"...

stas (2008-08-29 12:13:00) [76]
Ega23 © (29.08.08 12:11) [9]
т.е. для определения операции?

Ega23 (2008-08-29 12:11:00) [77]

> Для чего эта проверка?

А как, по-твоему, устроена операция Update? Сначала Delete, потом Insert

Ega23 (2008-08-29 12:09:00) [78]

> профессионалы стараются избегать триггеров
>

+1.

> А как же тогда логирование изменений, обеспечение целостности
> информации и т.д. ?

целостность данных обеспечивается средствами самой СУБД, такими как PK-FK constraints, нафига для этой цели триггеры - непонятно.

Логгирование отлично обеспечивается из других мест (ХП, например).

За 8+ лет работы с БД триггер понадобился один единственный раз.

stas (2008-08-29 12:09:00) [79]
Для чего эта проверка?

>
> IF EXISTS(SELECT * FROM Inserted)
> BEGIN
> IF NOT EXISTS(SELECT * FROM Deleted)

Игорь Шевченко (2008-08-29 12:08:00) [80]

> А как же тогда логирование изменений, обеспечение целостности
> информации и т.д.

целостность информации обычно обеспечивается декларативными средствами.

Про транзакции и триггеры рекомендую почитать:
http://sql.ru/forum/actualthread.aspx?tid=588877все страницы

Страницы: < 1 2 3 4 5 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »