Статьи по программированию
примеры программного кода
Delphi, Kylix, C, C++, SQL, Visual Basic, Bash, Assembler, 1С
Qt, KOL, MFC, Rx Library, Windows, Linux, Mac OS
Создание уникальных значений ключа в Interbase.
Опубликовано codeLocker в 08.08.2008 в 10:54.
При создании любой информационной системы с использованием SQL сервера возникает проблема генерации значения ключа в таблице. Целью данной статьи является рассмотрение вопросов, связанных с данным процессом.
Итак, представим, что у нас есть таблица TABLE1 :
(
ID INTEGER NOT NULL,
NAME VARCHAR(50) NOT NULL,
ADR VARCHAR(20) NOT NULL,
constraint PK_TABLE1 PRIMARY KEY (ID)
);
Нам необходимо обеспечить уникальность каждого кортежа в этой сущности TABLE1. Для этого существуют 3 способа:
1. Неправильный
В чем он заключается... Идея очень проста - при добавлении записей получаете максимальное значение ключа (select max(ID) from TABLE1), увеличиваете его на некоторую величину и используете в запросе (insert into table1 values(максимальное_значение_ключа+1,......) Недостатки этого способа достаточно очевидны - при многопользовательской работе возникают конфликты, когда несколько клиентов, пишущих в БД, получают одинаковые значения ключа.
2. Непереносимый
В чем он заключается... Использование этого метода основанно на механизме ГЕНЕРАТОРОВ в Interbase. Генератор - это особый механизм, гарантирующий, что при каждом обращении к нему будет генерироваться новый ключ.
Синтаксис - CREATE GENERATOR <имя генератора>;
Далее можно установить, с какой величины будет генерироваться ключ.
Синтаксис - SET GENERATOR <имя генератора> TO <начальное значение генератора>;
Далее создается хранимая процедура
RETURNS (ID INTEGER)
AS
BEGIN
ID = GEN_ID( <имя генератора>, <приращение генератора>);
END !!
После этого в Delphi кидаем на форму объект TStoredProc, прописываем в свойствах Alias и выбираем имя процедуры. При необходимости сгенерировать значение ключа пишем что-то типа:
sp_InNaklTextId.ExecProc;
PRIM_KEY:=sp_InNaklTextId.Params[0].AsInteger;
И далее Prim_key используем в запросе на добавление записи.
3. Переносимый
Идея состоит в некотором видоизменении 2 способа. Все также объявляем генератор, но вот хранимой процедуры больше нет, зато есть триггер. Выглядит это примерно так:
SET generator TABLE1_GEN TO 0;
commit;
SET term !! ;
CREATE TRIGGER TRG_TABLE1_INSERT FOR TABLE1
before INSERT
AS begin
new.ID= GEN_ID(TABLE1_GEN,1);
end!!
SET term ; !!
commit;
Далее при добавлении записи запрос указывает в виде:
VALUES('xxx','xxx');
В общем появляется некоторое неудобство при написании запросов, так как первое поле ключевое, и надо указать, что в него запись не производиться.
Главное же преимущество такого подхода в том, что увеличивается переносимость приложения между различными SQL серверами. Идея создания автогенератора ключа не нова - это и AutoIncrement поле в Paradox, и тип поля Identity в Ms SQL Server / Sybase, и вроде бы тоже некий тип поля в Oracle (к сожалению не знаю точно). Но эти механизмы не стандартизованны и каждый реализует их по своему. Описанный же выше подход обеспечивает переносимость, и, например, одно из написанных мною приложений, если не брать в расчет хранимые процедуры, одинаково работает и на IB и на MS SQL.
Материал похожий на Создание уникальных значений ключа в Interbase.
- Создание UDF для InterBase
- Установка Interbase и добавление пользователя
- Разработка запросов
- Interbase BLOB-поля