Как в FB сделать ключевое составное вычисляемое поле ?

← →
Trok (2004-01-12 14:19) [0]

Мастаки!

Как решить след. трабл. Надо чтобы ключевое поле генерилось ввиде:
код_из_таблицы_настроек+автоикремент
Т.е. есть таблица в которой есть поле отвечающее за териториальный признак, допустим AREA VARCHAR(3)
Там будет значения допустим AR1. У других пользователей AR2 и т.д.
И будет еще одна таблица где будет ключевое поле генерится на основе генератора и AREA: AR12000 например.
Таким образом я хочу решить проблему уникальности ключевого поля у БД разбитой на части и разнесенной териториально.
Как это реализовать? Генератором + триггер?

← →
Карелин Артем © (2004-01-12 14:45) [1]

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

CREATE TRIGGER MSS_BI FOR MSS ACTIVE BEFORE INSERT POSITION 1 AS declare variable c varchar(100); declare variable i integer; BEGIN select first(1) mss.id from mss into :i; c=cast(current_timestamp as varchar(10))||cast(i as varchar(7))||cast(gen_id(mss_id_gen,1)as varchar(10)); new.msstext =c; END
Думаю понять принципы не сложно.

← →
GLFox (2004-01-12 14:46) [2]

Делаешь, например, stored procedure с двумя запросиками, которая будет тебе генерить ID и выдавать:

select gen_id(<Generator>,1) form RDB$DATABASE
into :iTmp1;
select AREA from <TBL_OPTIONS> ...какой-то там...
into :sTmp2;

Превращаешь iTmp1 в стрингу, склеиваешь всю енту фигню.
Хотя конечно, это может быть и триггер.

← →
Trok (2004-01-12 14:48) [3]

Понятно. Спасибо.
Это нормальный способ(который я хочу реализовать) для гарантирования уникальности в таких(разбитых на части, а потом сливаемых в одну) БД? Или есть более надежный методы?

← →
Карелин Артем © (2004-01-12 14:51) [4]

Уникальность генераторов вроде как гарантирована...

← →
Johnmen © (2004-01-12 14:56) [5]

>Карелин Артем © (12.01.04 14:51)

В рамках одной БД.

>Trok
>Генератором + триггер?

Да.

← →
Карелин Артем © (2004-01-12 15:08) [6]

Плохо я прочитал. Для "сливаемых" в одну баз трбуется как минимум обеспечение уникальности признака базы. У меня это в программе используется составной уникальный ключ из генератора, кода региона и кода инспекции. Все это разнесено по отдельным полям для удобства поиска. Одна инспекция работает с одной базой. Можно сделать шаг генератора не 1 а к примеру 100 и у каждой базы сотворить свое начальное значение генератора.

← →
Trok (2004-01-12 15:44) [7]

Спасибо за советы, а какой тип выбрать для поля? varchar или integer? с varchar легче реализовать, а как с integer?
(если например AREA сделать не текстовым а числовым)
формировать строку 100 + 100002 = 100100002
а потом cast( str as integer )? что лучше будет для производительности?

← →
Johnmen © (2004-01-12 15:46) [8]

А зачем одно поле ? Можно же и два. В одном ареа в др. - знач. ген-ра.

← →
Trok (2004-01-12 15:58) [9]

Хорошо, так исделаю. Это таблица у меня адрес клиента. И я хотел сделать на этот составной ключ внешний ключ из другой таблицы - Клиент. Или просто перед добавлением в Клиент записи писать туда сгенерированый код адреса(выполнив соотсветсвующий запрос)?

← →
Vemer © (2004-01-12 15:59) [10]

С двумя ключами FK плохо делать, иногда нужно. А для первичного ключа лучше CHAR наверно, он быстрее индексируеться (по учебнику:)).

Согласен с Johnmen © (12.01.04 15:46) [8]
По-моему лучше 2 поля.
Представь себе, что тебе потребовалась выборка всех значений из одной базы-источника.
Что, будешь делать так, что ли?
select .. from .. where .. like "AR1%"
И зачем эти сиволы "AR" ?

2 Vemer © (12.01.04 15:59) [10]
Чем это FK с двумя полями плох?
К тому же ничто не мешает сделать одно суррогатное поле для таких целей (собственно первичный ключ):
ID INTEGER первичный ключ,
BASE_ID, LOCAL_ID альтернативный ключ (собственно ключ)

← →
Trok (2004-01-12 16:07) [13]

to kaif
AR - это я так для примера привел. У меня все будет привязано к нас. пункту. За ним закреплен код територии - например 40678(это не почтовый индекс). вот его я и буду писать в AREA NUMERIC(5,0)
А генератором буду создавать ID_ADDRESS INTEGER.
Ключ построю по этим двум полям:
ALTER TABLE ADDRESS ADD CONSTRAINT ADDRESS_PK PRIMARY KEY (ID_ADDRESS, TE);

To Kaif
Я сам 2 поля использую, но мне FK не нужен. А FK по двум полям не делаеться (у меня не получилось). А делать 2 поля а потом еще и суррогатное - уж проще сразу 1 сделать и не париться..

2 Vemer © (12.01.04 16:17) [14]
Как не делается, если делается? Приведи пример, как ты пытался сделать FK по двум полям.

2 Trok (12.01.04 16:07) [13]
Лучше вместо AREA NUMERIC(5,0) использовать INTEGER. Это самое быстрое поле для обработки на процессорах Intel (32бит). А NUMERIC(5,0) все равно будет приведено к INTEGER. Только я боюсь еще потеряется время на перекодировки всякие. Хотя не уверен. Но используя вместо него INTEGER ты точно ничего не потеряешь, и возможно даже выиграешь в скорости и простоте.

Как в FB сделать ключевое составное вычисляемое поле ? Найти похожие ветки