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

Два поведения могут привести к огромному объему пакетных операций, резко замедляющих выполнение.

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

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

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

ALTER INDEX имя-индекса INACTIVE;

Когда большая пакетная операция закончится, реактивируйте и пересоздайте индексы:

ALTER INDEX имя-индекса ACTIVE;

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

При помещении в базу данных большого количества данных в пакете предпочтительным является разбиение их на группы и подтверждение работы приблизительно через каждые 5000-10 000 строк. Фактический размер оптимального разбиения будет меняться в зависимости от размера строки и размера страниц базы данных. Оптимальные группы могут быть меньше или больше указанного диапазона.

! ! !

СОВЕТ. Когда вам нужно разделять огромные пакеты, часто хранимые процедуры являются способом это сделать. Вы можете использовать локальные переменные-счетчики, сообщения о событиях и возвращать значения для сохранения вызова процедуры с целью синхронизации с вызовами клиента.

. ! .

Firebird включает некоторые особенности, которые могут быть использованы при проектировании базы данных для реагирования на операции DML, которые изменяют состояние данных, - а именно выполнение операторов INSERT, UPDATE и DELETE.

Триггеры ссылочной целостности являются модулями компилированного кода, создаваемыми ядром сервера, когда вы объявляете ограничение ссылочной целостности для ваших таблиц. Включив предложения действия ON UPDATE и ON DELETE В объявление ограничения FOREIGN KEY, вы можете задать одно из группы действий, которое будет выполняться при наступлении соответствующего события DML. Подробности см. в главе 17.

В пользовательских триггерах (тех, которые вы пишете сами, используя язык PSQL) у вас есть возможность точно задать, что происходит, когда сервер получает запрос на добавление, изменение или удаление строк таблицы. Пользовательские триггеры

могут применяться не только для изменения и удаления, но также и для добавления.

Триггеры могут включать обработку исключений, обратные связи и (для Firebird 1.5) пользовательские планы запросов.

Синтаксис триггера разделяет пользовательские действия DML на две фазы: первая

фаза появляется до (BEFORE) события, а вторая после (AFTER) события.

* Фаза BEFORE дает возможность управлять преобразованием значений, которые являются входными в операторе DML, и определять значения по умолчанию гораздо более гибкими способами, чем это позволено в стандартном SQL-ограничении DEFAULT. Фаза BEFORE завершается перед тем, как начинают проверяться любые ограничения столбца, таблицы или ограничения целостности.

* В фазе AFTER ответные действия могут быть выполнены над другими таблицами. Обычно такие действия включают добавления, изменения или удаления данных других таблиц с использованием переменных NEW и OLD для обеспечения контекста текущей строки и операции. Фаза AFTER начинается после применения всех ограничений собственной таблицы. Триггеры AFTER не могут изменять значения в текущей строке собственной таблицы.

Табл. 20.1 описывает шесть фаз/событий пользовательских триггеров.

Таблица 20.1. Шесть фаз/событий пользовательских триггеров