2. Особенности применения триггера

При использовании триггеров необходимо учитывать следующее:

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

• Триггер может быть привязан только к одной таблице.

• У одной таблицы может быть много триггеров разных типов.

• Триггеры могут быть на добавление, изменение и удаление (insert, update, delete) в любых вариациях.

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

• Если в триггере изменяются данные по таблице, к которой привязан триггер, то вся группа триггеров по этой таблице выполняется повторно за исключением этого триггера (если в опциях сервера стоит метка "allow nested triggers").

• Писать триггеры надо так, чтобы не была важна последовательность их вызова.

Пример триггера, который выполняет проверку наличия необходимого товара на складе

CREATE TRIGGER Триггер_ins

ON Сделка FOR INSERT

AS

IF @@ROWCOUNT=1

BEGIN

IF NOT EXISTS(SELECT *

FROM inserted

WHERE inserted.количество<=ALL(SELECT

Склад.Остаток

FROM Склад,Сделка

WHERE Склад.КодТовара=

Сделка.КодТовара))

BEGIN

ROLLBACK TRAN

PRINT

'Отмена поставки: товара на складе нет'

END

END

Лекция 8. Транзакции.

Обеспечение параллелизма при реализации SQL-запросов. Понятие транзакций. Уровни изолированности транзакций. Распределенные транзакции. Методы управления транзакциями.

1. Проблемы параллелизма

Современные СУБД являются многопользовательскими системами, т.е. допускают параллельную одновременную работу большого количества пользователей. При этом пользователи, как правило, не знают о том, работают ли с этими данными дркгие пользователи (или приложения). Для организации такой многопользоватеьской работы была определена логическая единица работы пользователя с БД –транзакция. Работа СУБД организуется таким образом, что у пользователя складывалось впечатление, что их транзакции выполняются независимо от транзакций других пользователей.

Простейший и очевидный способ обеспечить такую взможность состоит в том, чтобы все поступающие транзакции выстраивать в единую очередь и выполнять строго по очереди. Однако, такой способ не подходит по вполне очевидным причинам – теряется преимущество параллельной работы и сущемственно увеличивается время выполнения запросов пользователей к БД. Таким образом, транзакции необходимо выполнять одновременно, но так, чтобы результат был бы такой же, как если бы транзакции выполнялись по очереди. Основная сложность заключается состоит в том, что если не предпринимать никаких специальных мер, то данные измененные одним пользователем могут быть изменены транзакцией другого пользователя раньше, чем закончится транзакция первого пользователя. В результате, в конце транзакции первый пользователь увидит не результаты своей работы. Т.е. при таком подходе будет нарушена целостность БД при одновременной работы многих пользователей.