1.6.1. Реализация автоинкрементных полей

Рекомендованное использование в СУБД Firebird триггеров before insert предназначено для реализации автоинкрементных первичных ключей. Эта техника проста, и она включает два шага:

Создание генератора для генерации уникальных чисел ключа;

Написание триггера before, insert для таблицы.

Для иллюстрации этой техники реализуем автоинкрементный первичный ключ для таблицы customer, у которой первичный ключ custoker_id - столбец целого типа bigint.

Во-первых, создадим генератор:

CREATE GENERATOR GEN_PK_CUSTOKER;

Затем создадим триггер:

CREATE TRIGGER BI_CUSTOMER FOR CUSTOMER

ACTIVE BEFORE

INSERT POSITION 0

ASCREATE TRIGGER BI_CUSTOMER FOR CUSTOMER

ACTIVE BEFORE INSERT POSITION 0

AS

BEGIN

IF (NEW.CUSTOMER_ID IS NULL) THEN

NEW.CUSTOMER_ID = GEN_ID(GEN_PK_CUSTOMER, 1) ;

Когда выполняется добавление, custcmer_id сознательно не указывается во входном списке оператора insert:

INSERT INTO CUSTOMER (

LAST_NAME,

FIRST_NAiME,

. . . )

VALUES (?, ?, ...) ;

Без триггера этот оператор вызовет исключение, потому что первичный ключ не может иметь пустого значения. Однако триггер before insert выполняется до проверки этого ограничения, он контролирует, что customer_id имеет пустое значение, и выполняет свое действие.

В приведенном примере выполняется проверка NEW.значение на NULL.

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

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

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

SELECT GEN_ID[GEN_PK_CUSTOMER, 1) AS RESULT FROM RDBSDATABASE;

Если в вашем триггере опущена проверка на пустое значение и просто выполняется:

NEW.CUSTOMER_ID = GEN_ID (GEN_PK_CUSTCMER, 1);

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

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

Ниже приведен SQL-скрипт для создания триггера для таблицы OWNER в базе данных Realt.fdb

SET SQL DIALECT 3;

SET NAMES WIN1251;

SET TERM ^ ;

CREATE TRIGGER OWNER_BI0 FOR OWNER

ACTIVE BEFORE INSERT POSITION 0

AS

begin

if (new.id is null) then

new.id=gen_id(gen_owner_id,1);

end

^

SET TERM ; ^

На рисунке 1.6.1. показано как создается триггер для организации автоинкриментного поля ID в таблице OWNER базы данных Realt.fdb с использование утилиты IBExpert.

Рисунок 1.6.1. Создание триггера в таблице OWNER с использование утилиты IBExpert

Содержание

Лабораторная работа №6 1

Цель работы 1

Порядок выполнения работы 1

Содержание отчета 2

Теоретическая часть 2

Общая постановка задачи 2