Обработка баз данных на Visual Basic®.NET

Прайс Кевин Т.

Не нужно использовать триггеры для поддержки ссылочной целостности; для этого лучше обратиться к встроенным средствам SQL Server. Старайтесь при работе с базами данных использовать средства, предоставляемые SQL Server.

Например, можно использовать триггеры, чтобы обеспечить уникальное значение в столбце для сохранения первичного ключа. Этот способ характерен для программы Microsoft Access Upsizing Tools; в ней генерируется случайное значение первичного ключа каждой записи с помощью триггера. (Для этого можно использовать уникальное поле, как уже упоминалось ранее в главе.) Пример такого кода генерации первичного ключа приведен ниже.

CREATE TRIGGER tblCustomer_ITrig ON dbo.tblCustomer

FOR INSERT

AS

DECLARE @randc int, @newc int

SELECT @randc = (SELECT convert(int, rand * power(2, 30)))

SELECT @newc = (SELECT ID FROM inserted)

UPDATE tblCustomer SET ID = @randc WHERE ID = @newc

НА

ЗАМЕТКУ

Для корректной работы каждого из этих триггеров и обновления идентификационного поля нужно переустановить значения этого поля таким образом, чтобы оно не считалось идентификационным. Для этого перейдите в диалоговое окно Design Table и задайте для свойства Identity(Идентификационное поле) значение No.

Создание первичного ключа записи на основе случайного значения – самый простой способ уникальной идентификации записи. Однако такой способ имеет два недостатка.

Во-первых, первичный ключ генерируется в произвольном порядке. В некоторых случаях это не очень существенная проблема, однако если использовать первичный ключ для нумерации выписываемых счетов, то может случиться так, что счет с номером 20010 будет выписан раньше, чем счет с номером 20009.

Во-вторых, существует потенциальная проблема, состоящая в том, что сгенерированный уникальный ключ на самом деле не будет уникальным, т.е. при создании ключа не выполняется проверка существования записи с таким же значением первичного ключа. Конечно, вероятность того, что будет сгенерировано два одинаковых значения, очень мала, но она все же существует (тип данных integer в SQL Server имеет длину 4 бита, т.е. диапазон возможных значений: -2,1×10⁹…2,1×10⁹).

Бизнес-ситуация 3.1: создание триггера для поиска созвучных слов

Брэд Джонс, президент компании Jones Novelties Incorporated, одобрил предварительную работу своего разработчика базы данных. Теперь он готов приступить к следующей проблеме, связанной с базой данных, и создать запросы для извлечения информации о клиентах по введенному созвучному имени (например, имена произносятся одинаково, но пишутся по-разному) с учетом случайных опечаток в нем. Как организовать поиск клиента, если вы не помните точное написание его имени, а только его произношение: Smith или Smyth, McManus или MacManus? Каждому человеку с необычной фамилией наверняка приходилось сталкиваться с ее неверной записью на слух.

Разработчик базы данных для решения этой проблемы решил воспользоваться функцией soundex, специально предусмотренной для этого в SQL Server. Она преобразует слово в алфавитно-цифровое значение, которое представляет базовые звуки слова. Если такое значение создается в момент ввода имени, то поиск имени можно вести по его алфавитно-цифровому значению. Конечно, такой запрос вернет гораздо больше записей, чем нужно, но все они будут отвечать одному произношению.

Для реализации этого компонента в базе данных Jones Novelties нужно выполнить следующие действия:

• изменить таблицу tblCustomer для вставки нового поля LastNameSoundex;

• запустить запрос обновления данных для создания

алфавитно-цифровых значений звучания для имен клиентов в таблице tblCustomer;

• создать триггер, который сгенерирует в поле LastNameSoundex алфавитно-цифровое значение звучания для введенного или измененного имени;

• создать хранимую процедуру, которая возвращает всех клиентов с одинаково звучащими именами.

Разработчик базы данных начинает с создания нового поля LastNameSoundex в таблице tblCustomer для хранения в нем алфавитно-цифровых значений звучания имен всех клиентов. Это можно сделать с помощью следующей команды:

ALTER TABLE tblCustomer ADD

LastNameSoundex varchar(4) NULL

Затем разработчику нужно создать и только один раз выполнить команду UPDATE для вычисления алфавитно-цифровых значений звучания уже имеющихся имен в базе данных.

UPDATE tblCustomer

SET LastNameSoundex = soundex(lastName)

GO

SELECT LastName, LastNameSoundex

FROM tblCustomer

GO

Включать команду SELECT в пакет команд SQL после команды UPDATE совсем необязательно, это нужно лишь для того, чтобы разработчик базы данных смог убедиться в правильности выполненных действий.

Далее разработчику нужно создать триггер, чтобы вставить алфавитно-цифровое значение звучания для каждого введенного в базу данных имени нового клиента.

CREATE TRIGGER trCustomerT

ON tblCustomer

FOR insert, update

AS

 UPDATE tblCustomer

 SET tblCustomer.LastNameSoundex = soundex(tblCustomer.LastName)

 FROM inserted

 WHERE tblCustomer.ID = inserted.ID

НА ЗАМЕТКУ

Хотя в SQL Server 2000 для одной таблицы допускается определение нескольких триггеров одного типа (для вставки, обновления и удаления), но порядок их выполнения контролируется только частично, т.е. можно указать только первый и последний выполняемый триггер. Для гарантированного выполнения данного триггера после всех триггеров вставки для таблицы tblCustomer (например, триггера присвоения значения столбцу ID) нужно выполнить в программе SQL Query Analyzer следующую команду:

sp_settriggerorder @triggername=@order='last', @stmtype='INSERT'

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

Для обработки нужного набора записей триггеру должно быть известно, какие записи участвовали в выполнении процедуры, которая привела к ее запуску. Откуда же у триггера такие сведения? Триггеры обладают доступом к этой информации благодаря виртуальным таблицам вставки и удаления. Виртуальная таблица вставки содержит записи, вставленные (или обновленные) процедурой, которая привела к запуску триггера вставки. Аналогично, виртуальная таблица удаления содержит записи, удаленные процедурой, которая привела к запуску триггера удаления.