Хелен Борри - Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ

aQuery.ParamByName ('SALES_DATE').AsDate := ALocalDateVariable;

Очень часто требуется выполнение задач, которые добавляют, изменяют или удаляют множество строк в одной операции. Например, приложение читает файл данных с внешнего устройства и помещает данные в операторы INSERT для помещения в таблицу базы данных. или сервис репликации обрабатывает пакеты изменений между вспомогательной и родительской базами данных. Множество похожих операторов выполняется в одной транзакции обычно с помощью подготовленного оператора и заменяемых во время выполнения параметров.

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

INSERT INTO DATATABLE(DATA1, DATA2, DATA3, DATA4, DATA5, . . . другие столбцы)

VALUES ('x', 'у', 'z', 99, '2004-12-25', . . . другие значения);

При использовании параметров он будет выглядеть так:

INSERT INTO DATATABLE(DATA1, DATA2, DATA3, DATA4, DATA5, . . . другие столбцы)

VALUES (?, '?', '?', ?, ?, .... другие значения);

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

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

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

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

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

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. Шесть фаз/событий пользовательских триггеров

Сервер делает доступными для триггеров два набора контекстных переменных. Один состоит из всех значений полей текущей строки, какими они были перед последним помещением этой строки в базу данных. Идентификаторы этого набора состоят из слова "OLD.", за которым следует идентификатор столбца. Аналогичным образом все новые значения имеют префикс "NEW." перед каждым идентификатором столбца. Разумеется, "OLD." не имеет смысла в триггерах добавления, a "NEW." бессмысленно использовать в триггерах удаления.

В Firebird 1.5 и выше вы можете писать триггеры с условной логикой для всех событий (добавление, изменение и удаление) для одной из фаз- BEFORE или AFTER - в одном модуле триггера. Это долгожданное улучшение, которое уменьшает кодирование триггеров на две трети.