- •1.2.2Типы представлений — до 5 мин.
- •1.2.3Создание представлений — до 25 мин.
- •1.2.4Использование представлений — до 10 мин.
- •1.2.5Изменение и удаление представлений — до 5 мин.
- •1.2.6Индексированные представления — до 5 мин.
- •2.2.2Создание хранимых процедур — до 15 мин.
- •2.2.3Использование параметров — до 15 мин.
- •2.2.4Использование локальных переменных внутри хранимой процедуры — до 15 мин.
- •2.2.5Использование return для возвращаемых значений — до 10 мин.
- •2.2.6Использование select для возвращаемых значений — до 10 мин.
- •2.2.7Управление хранимыми процедурами с помощью t-sql — до 10 мин.
- •3.2.2Когда использовать триггеры —до 10 мин.
- •3.2.3Создание триггеров — до 10 мин.
- •3.2.4Создание триггера типа delete — до 10 мин.
- •3.2.5Создание триггера типа insert — до 5 мин.
- •3.2.6Создание триггера типа update — до 10 мин.
- •3.2.7Создание триггера instead of — до 10 мин.
- •3.2.8Использование триггеров after — до 5 мин.
- •3.2.9Использование вложенных триггеров — до 10 мин.
- •3.2.10Управление триггерами с помощью операторов t-sql — до 5 мин.
- •4.2.2Уровни изолированности — до 10 мин.
- •4.2.3Поведение параллельных транзакций — до 10 мин.
- •4.2.4Режимы транзакций — до 20 мин.
- •4.2.5Вложенные транзакции — до 15 мин.
- •4.2.6Откаты транзакций — до 15 мин.
- •4.2.7Точки сохранения — до 10 мин.
- •5.2.2Уровни блокировок — до 15 мин.
- •5.2.3Режимы блокировки — до 20 мин.
- •5.2.4Блокирование и взаимоблокировки — до 20 мин.
- •5.2.5Подсказки блокировки — до 20 мин.
- •6.2.2Логическая оптимизация запросов — до 20 мин.
- •6.2.3Оптимизация плана исполнения запроса — до 15 мин.
- •6.2.4Подсказки оптимизатору запросов — до 15 мин.
- •6.2.5Оптимизация с использованием sql Server 2000 Index Tuning Wizard и sql Server 2005 Database Tuning Advisor — до 30 мин.
- •7.2.2Режимы аутентификации — до 15 мин.
- •7.2.3Учетные записи и пользователи — до 20 мин.
- •7.2.4Администрирование полномочий доступа к базам данных — до 20 мин.
- •7.2.5Администрирование ролей баз данных — до 10 мин.
- •7.2.6Делегирование учетной записи безопасности — до 15 мин.
- •8.2.2Внедрение sql кода (sql Injection) — до 20 мин.
- •8.2.3Защита sql Server в Интернет — до 20 мин.
- •8.2.4Пример организации системы безопасности приложений — до 40 мин.
- •9.2.2Журнальное протоколирование в sql Server — до 20 мин.
- •9.2.3Контрольные точки — до 15 мин.
- •9.2.4Методы резервного копирования — до 25 мин.
- •10.2.2Слежение за резервным копированием — до 10 мин.
- •10.2.3Планирование резервного копирования — до 25 мин.
3.2.2Когда использовать триггеры —до 10 мин.
Триггеры, как и ограничения, можно использовать для поддержки целостности данных и деловых правил, но триггер не следует использовать как замену ограничения, когда достаточно использовать только ограничение. Например, вам не нужно создавать триггер, который проверяет наличие значения в колонке первичного ключа одной таблицы, чтобы определить, можно ли вставить это значение в соответствующую колонку другой таблицы; в этой ситуации прекрасно подойдет ограничение FOREIGN KEY. Однако вам может потребоваться триггер для каскадирования изменений, вносимых в связанные таблицы базы данных. Например, вы можете создать триггер DELETE по колонке title_id в таблице titles базы данных pubs, который удалит строки в таблицах sales, roysched и titleauthor, если удаляется соответствующая строка в таблице titles. (Мы увидим в следующем разделе, как создать этот триггер DELETE.)
Вы можете также использовать триггеры для проведения более сложных проверок по данным, чем это допускается при использовании ограничения CHECK. Дело в том, что триггеры могут обращаться к колонкам таблиц, отличных от таблицы, по которой они определены, в то время как ограничения CHECK действуют в рамках только одной таблицы.
Триггеры также полезно использовать для выполнения нескольких операций в ответ на одно событие модификации данных. Если вы создаете несколько триггеров для одного типа события модификации данных, то все эти триггеры будут активизироваться, когда происходит это событие. (Следует помнить, что если несколько триггеров определено по таблице или представлению для какого-либо события, то каждый триггер должен иметь уникальное имя.)
Вы можете создать один триггер, который будет активизироваться для нескольких типов событий модификации данных. Этот триггер будет активизироваться каждый раз, когда будет возникать событие, для которого он определен. Поэтому триггер, определенный по определенной таблице или представлению для вставок, изменений и удалений, будет активизироваться при каждом возникновении любого из этих событий по данной таблице или представлению.
Когда вы создаете какой-либо триггер, SQL Server создает две специальные временные таблицы. Вы можете обращаться к этим таблицам при написании T-SQL-программы, которая образует определение этого триггера. Эти таблицы всегда находятся в памяти и являются локальными по отношению к данному триггеру, и каждый триггер имеет доступ только к своим временным таблицам. Эти временные таблицы являются копиями таблицы базы данных, по которой определяется данный триггер. Вы можете использовать эти временные таблицы, чтобы увидеть влияние, оказанное каким-либо событием модификации данных на исходную таблицу. Вы увидите примеры этих специальных таблиц (с именами deleted и inserted) в следующем разделе.
3.2.3Создание триггеров — до 10 мин.
Чтобы использовать T-SQL для создания триггера, нужно применить оператор CREATE TRIGGER. Он имеет следующий синтаксис:
CREATE TRIGGER имя_триггера
ON {таблица | представление}
[WITH ENCRYPTION]
{FOR | AFTER | INSTEAD OF}
{[DELETE] [,] [INSERT] [,] [UPDATE]}
[WITH APPEND]
[NOT FOR REPLICATION]
AS
оператор_sql [...n]
Как видно из этого описания, вы можете создать триггер для оператора INSERT, UPDATE, DELETE, INSTEAD OF или AFTER или для любой комбинации из этих пяти операторов. Вы должны задать хотя бы одну опцию с предложением FOR. Это предложение указывает, возникновение какого типа события модификации данных (или типов событий) по указанной таблице приведет к активизации данного триггера.
При вызове триггера будут выполнены операторы SQL, указанные после ключевого слова AS. Вы можете поместить сюда несколько операторов, включая программные конструкции, такие как IF и WHILE. В определении триггера не допускаются следующие операторы: ALTER DATABASE, CREATE DATABASE, DISK INIT, DISK RESIZE, DROP DATABASE, LOAD DATABASE, LOAD LOG, RECONFIGURE, RESTORE DATABASE, RESTORE LOG.
Использование таблиц deleted и inserted
Как уже говорилось, при создании триггера вы имеете доступ к двум временным таблицам с именами deleted и inserted. Их называют таблицами, но они отличаются от реальных таблиц баз данных. Они хранятся в памяти, а не на диске.
Эти две таблицы имеют одинаковую структуру с таблицей (одинаковые колонки и типы данных), по которой определяется данный триггер. Таблица deleted содержит копии строк, на которые повлиял оператор DELETE или UPDATE. Строки, удаляемые из таблицы данного триггера, перемещаются в таблицу deleted. После этого к данным таблицы deleted можно осуществлять доступ из данного триггера. Таблица inserted содержит копии строк, добавленных к таблице данного триггера при выполнении оператора INSERT или UPDATE. Эти строки добавляются одновременно в таблицу триггера и в таблицу inserted. Поскольку оператор UPDATE обрабатывается как DELETE, после которого следует INSERT, то при использовании оператора UPDATE старые значения строк копируются в таблицу deleted, а новые значения строк – в таблицу триггера и в таблицу inserted.
Если вы попытаетесь проверить содержимое таблицы deleted из триггера, который активизирован в результате выполнения оператора INSERT, эта таблица окажется пустой, но сообщение об ошибке не возникнет. Выполнение оператора INSERT не приводит к копированию значений строк в таблицу deleted. Аналогичным образом, если вы попытаетесь проверить содержимое таблицы inserted из триггера, который активизирован в результате выполнения оператора DELETE, эта таблица окажется пустой. Выполнение оператора DELETE не приводит к копированию значений строк в таблицу inserted. И здесь просмотр пустой таблицы не приведет к сообщению об ошибке; поэтому для использования этих таблиц с целью просмотра результатов модификаций убедитесь в том, что для доступа из триггера у вас выбрана соответствующая таблица.
Значения таблиц inserted и deleted доступны только из триггера. После завершения работы триггера эти таблицы больше не доступны.
Пример создания триггера
Чтобы увидеть, как работает триггер, создадим простую таблицу с определенным по ней триггером, который печатает определенный текст при каждой модификации. Программа T-SQL для создания этой таблицы имеет следующий вид:
CREATE TABLE Bicycle_Inventory
(
make_name char(10) NOT NULL,
make_id tinyint NOT NULL,
model_name char(12) NOT NULL,
model_id tinyint NOT NULL,
in_stock tinyint NOT NULL,
on_order tinyint NULL,
)
GO
IF EXISTS (SELECT name FROM sysobjects
WHERE name = "Print_Update" AND type = "TR")
DROP TRIGGER Print_Update
GO
CREATE TRIGGER Print_Update
ON Bicycle_Inventory
FOR UPDATE
AS
PRINT "The Bicycle_Inventory table was updated"
GO
Чтобы проверить триггер, выполним вставку строки в эту таблицу и затем модифицируем ее:
INSERT INTO Bicycle_Inventory VALUES ("Trek",1,"5500",5,1,0)
GO
UPDATE Bicycle_Inventory SET make_id = 2
WHERE model_name = "5500"
GO
Будет возвращено сообщение "The Bicycle_Inventory table was updated", так как в результате выполнения оператора UPDATE был запущен триггер. В данном примере мы задали в нашем триггере вывод сообщения, чтобы можно было увидеть работу этого триггера. Но обычно не требуется, чтобы триггер возвращал выходные данные. Однако в определенных обстоятельствах это может оказаться полезным. Например, предположим, что вы создаете триггер типа UPDATE, который выполняет свои операторы, только когда в указанную колонку заносится определенное значение, но эта модификация происходит неверно. Если добавить в триггер оператор PRINT, который выводит значение этой колонки до выполнения других операторов триггера, это, видимо, поможет определить, где лежит источник проблемы – в логике самого триггера или в модифицируемых данных.
