Форум: "Базы";
Текущий архив: 2004.02.06;
Скачать: [xml.tar.bz2];
ВнизКак в 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 наверно, он быстрее индексируеться (по учебнику:)).
← →
kaif (2004-01-12 16:02) [11]Согласен с Johnmen © (12.01.04 15:46) [8]
По-моему лучше 2 поля.
Представь себе, что тебе потребовалась выборка всех значений из одной базы-источника.
Что, будешь делать так, что ли?
select .. from .. where .. like "AR1%"
И зачем эти сиволы "AR" ?
← →
kaif (2004-01-12 16:05) [12]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);
← →
Vemer (2004-01-12 16:17) [14]To Kaif
Я сам 2 поля использую, но мне FK не нужен. А FK по двум полям не делаеться (у меня не получилось). А делать 2 поля а потом еще и суррогатное - уж проще сразу 1 сделать и не париться..
← →
kaif (2004-01-12 16:31) [15]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 ты точно ничего не потеряешь, и возможно даже выиграешь в скорости и простоте.
Страницы: 1 вся ветка
Форум: "Базы";
Текущий архив: 2004.02.06;
Скачать: [xml.tar.bz2];
Память: 0.48 MB
Время: 0.072 c