После жесткого подтверждения или отката другая транзакция может удалить строку, которая была изолирована внутри контекста вашей транзакции и, следовательно, рассматривалась как "существующая" в вашем приложении. Любое значение RDB$DB_KEY теперь может указывать на несуществующую строку. Если у вас достаточно большой интервал между моментом, когда начинается ваша транзакция и когда завершается ваша работа, вы должны проверять, не была ли за это время строка изменена или заблокирована другой транзакцией.
Некоторые интерфейсы приложений, например IB Objects, являются суперинтеллектуальными в плане добавлений и могут подготовить "сегмент" для вновь добавленных строк в клиентских буферах для быстрого обновления списка после подтверждения. Такие возможности важны для производительности при работе в сети. Однако "интеллектуальность", подобная этой, основывается на точных реальных ключах. Поскольку db_key является просто заменителем ключа для набора, наследуемого от предыдущих подтвержденных данных, он не имеет смысла для новой строки - он не доступен при изменениях в клиентском буфере.
Значение длительности действия по умолчанию для RDB$DB_KEY можно изменить во время соединения с базой данных, используя параметр API isc_dpb_dbkey_scope. Некоторые разработки - например, компоненты IB Objects в инструментах окружения Borland Object Pascal - предоставляют его в классе соединения. Однако не рекомендуется расширять область действия db key в высоко интерактивной среде, поскольку это остановит сборку мусора, приводя к нежелательному росту размера файла базы данных и замедлению работы системы вплоть до ее зависания или краха. Не используйте соединения, имеющие область действия для db key, отличающуюся от значения по умолчанию.
RDB$DB_KEY в многотабличных наборах
Все таблицы поддерживают свои собственные 8-байтовые столбцы RDB$DB_KEY. Просмотры и соединения во время выполнения генерируют db key путем конкатенации RDB$DB_KEY из строк исходных таблиц. Если вы используете RDB$DB_KEY в многотабличных наборах, будьте особенно внимательны при задании каждого из них.
RDB$DB_KEY не может быть использован между различными таблицами. Не существует возможности установить отношения зависимости между RDB$DB_KEY двух таблиц, за исключением реентерабельных (ссылающихся на себя) соединений.
Многие из техник, описанных в данной главе, применимы к любым модулям PSQL, которые вы создаете. Далее мы сфокусируем наше внимание на техниках и возможностях языка PSQL, которые вы сможете использовать при написании триггеров, автоматически реагирующих на изменение состояния данных в строке или на добавление новой строки.
ГЛАВА 31. Триггеры.
Триггеры - ключевые элементы среди возможностей, предоставляемых Firebird для централизованной реализации бизнес-правил внутри системы управления базой данных. Триггер является автономным модулем, который выполняется автоматически, когда выполняется запрос, который будет изменять состояние данных в таблице.
Для написания кодов триггеров используются техники PSQL и хранимых процедур. При этом триггеры не могут вызываться из приложений или других процедур. Соответственно, они не могут получать входные и возвращать выходные аргументы, как это возможно в процедурах. В дополнение к PSQL они включают некоторые контекстные расширения языка, применимые только в модулях триггеров.
Все триггеры в Firebird выполняются на уровне строки каждый раз, когда изменяется образ строки. Firebird поддерживает высокий уровень детализации при определении времени, последовательности и условий, при которых будет выполняться конкретный модуль триггера. Множество модулей может быть определено для каждой фазы и события.
Триггеры являются частью работы транзакции, в которой событие DML изменяет состояние строки. Если транзакция успешно подтверждается, все действия триггеров будут "приняты". Если будет выполнен откат транзакции, все действия триггера будут отменены.
Фаза, событие и последовательность
Триггер может выполняться в одной из двух фаз, связанных с запрошенными изменениями состояния данных: до (before) записи или после (after) нее. Он может применяться к одному из трех событий DML: добавление, изменение или удаление. Начиная с Firebird 1.5 возможно объединение действий триггера для двух или трех событий DML в одном модуле триггера до или после.
Фаза и событие
В табл. 31.1 представлены восемь типов модулей триггеров.
Таблица 31.1. Комбинации фаза/событие для модулей триггеров
Вид триггера |
Описание |
Версия |
BEFORE INSERT |
Вызывается до создания новой строки. Позволяет изменять входные значения |
Все |
AFTER INSERT |
Вызывается после создания новой строки. Не позволяет изменять входные значения. Обычно используется для модификации других таблиц |
Все |
BEFORE UPDATE |
Вызывается до создания новой версии записи. Позволяет изменять входные значения |
Все |
AFTER UPDATE |
Вызывается после создания новой версии записи. Не позволяет изменять входные значения. Обычно используется для изменения других таблиц |
Все |
BEFORE DELETE |
Вызывается до удаления существующей строки. Не принимает изменений никаких столбцов в строке |
Все |
AFTER DELETE |
Вызывается после удаления строки. Не принимает изменений никаких столбцов в строке. Обычно используется для модификации других таблиц |
Все |
BEFORE <событие> OR <событие> [OR <событие>] |
Вызывается до выполнения изменения любого требуемого состояния данных. Действия для события DML должны быть закодированы условно. Действие "Удаление" не может изменять никакие столбцы в строке |
1.5+ |
AFTER <событиё> OR <событие> [OR <событие>] |
Вызывается после выполнения изменения любого требуемого состояния данных. Действия для события DML должны быть закодированы условно. Действия не могут изменять никакие столбцы в строке. Обычно используется для модификации других таблиц |
1.5+ |
Последовательность
Для любой комбинации фаза/событие Firebird позволяет использовать множество триггеров. Вероятно, существует какое-то практическое ограничение, однако можно с уверенностью сказать, что вы можете создавать столько триггеров, сколько вам нужно с использованием целых чисел от 0 до 32 767. Последовательный номер по умолчанию (POSITION) ноль. Хорошей практикой является задание для триггера порядка выполнения, однако явное указание последовательности не является обязательным. Если присутствуют последовательные номера, триггеры будут выполняться в возрастающем порядке. Числа не должны быть уникальными, последовательность может иметь разрывы.
Набор триггеров для фазы/события со значением по умолчанию POSITION 0 будет выполняться в алфавитном порядке их имен. То же самое можно ожидать, если вы имеете группу триггеров, имеющих один и тот же не нулевой последовательный номер.
Следующий пример демонстрирует, как будут выполняться четыре триггера изменения (UPDATE) для таблицы ACCOUNT: