Справочники и первичный ключ

[voltron]

В базе используются справочные таблицы, которые состоят из двух строковых полей - CODE и NAME. Первое поле - уникальное в пределах справочника условное обозначение (для разных справочников разная длина, но не более 7 символов), а второе - расшифровка. Прочитав статью, решил дополнить эти таблицы суррогатным ключем на генераторе и использовать его в качестве первичного ключа.
Первый вопрос, который возник - насколько большой выигрыш будет от использования суррогатного ключа, справочники не сильно большие (2-130 строк) и с большой вероятностью меняться будут достаточно редко (если вообще будут), но в результаты запросов ВСЕГДА нужно подставлять расшифровку.
Второй вопрос связан с использованием данных из справочников в основных таблицах. Проблема в том, что информация в базу поступает в процессе программной обработки файлов, а в файлах используются условные обозначения. Если в качестве PK в справочниках использовать именно условное обозначение - то проблем с загрузкой данных и контролем нет. Если же использовать суррогатный ключ, то насколько понимаю, перед вставкой данных нужно выполнять дополнительные запросы для сопоставления условного обозначения и значения PK в справочнике. Или есть какие-то другие способы и можно обойтись без дополнительных запросов?

[Attid]

ИМХО если CODE не меняется и не будет , то делай его ПК и не парься

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

в эксперте забей данными на пару милионов и потестируй.

[kdv]

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

что означает, что статью не понял. у тебя CODE неуникальный? Если нет, зачем тебе понадобился суррогатный ПК? Разве CODE в твоем случае не суррогатный?

[KKomov]

В базе используются справочные таблицы, которые состоят из двух строковых полей - CODE и NAME. Первое поле - уникальное в пределах справочника условное обозначение (для разных справочников разная длина, но не более 7 символов), а второе - расшифровка. Прочитав статью, решил дополнить эти таблицы суррогатным ключем на генераторе и использовать его в качестве первичного ключа.
Первый вопрос, который возник - насколько большой выигрыш будет от использования суррогатного ключа, справочники не сильно большие (2-130 строк) и с большой вероятностью меняться будут достаточно редко (если вообще будут), но в результаты запросов ВСЕГДА нужно подставлять расшифровку.
Второй вопрос связан с использованием данных из справочников в основных таблицах. Проблема в том, что информация в базу поступает в процессе программной обработки файлов, а в файлах используются условные обозначения. Если в качестве PK в справочниках использовать именно условное обозначение - то проблем с загрузкой данных и контролем нет. Если же использовать суррогатный ключ, то насколько понимаю, перед вставкой данных нужно выполнять дополнительные запросы для сопоставления условного обозначения и значения PK в справочнике. Или есть какие-то другие способы и можно обойтись без дополнительных запросов?

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

Сам делал в точности такую вещь. Сделал справочники на искусственных ключах на генераторах, из экстремизма. Какое там ускорение на практике, не знаю.

Код вставки оказался не столь и страшным. Я сделал хранимые процедуры для вставки всех нужных видов записей. Приведу пример кода на всякий случай, вдруг вам чем-то поможет.

Код: Выделить всё

CREATE PROCEDURE SP_INSERT_EGRZ_RIGHT (
    type_code char(12),
    subject_name varchar(256),
    share integer,
    subject_jaddress varchar(2048),
    subject_inn char(30),
    doctype_code char(12),
    docname varchar(256),
    docno varchar(128))
returns (
    all_ok integer)
as
declare variable "TYPE" integer; /* Ссылка в справочник типов прав */
declare variable LOT integer; /* Участок, к которому прицепляем право */
declare variable DCOTYPE integer; /* Ссылка в справочник типов документов */
begin
  ALL_OK=0;
  SELECT MAX(ID) FROM EGRZ_LOTS INTO :LOT;
  SELECT ID FROM EGRZ_RIGHTTYPES WHERE EGRZ_CODE=:TYPE_CODE INTO :"TYPE";
  SELECT ID FROM EGRZ_DOCTYPES WHERE EGRZ_CODE=:DOCTYPE_CODE INTO :DOCTYPE;
  INSERT INTO EGRZ_RIGHTS(ID, LOT, "TYPE",
    SUBJECT, SUBJECT_NAME, SHARE, SUBJECT_JADDRESS, SUBJECT_INN,
    DOC, DOCTYPE, DOCNAME, DOCNO)
  VALUES(NULL, :LOT, :"TYPE",
    NULL, :SUBJECT_NAME, :SHARE, :SUBJECT_JADDRESS, :SUBJECT_INN,
    NULL, :DOCTYPE, :DOCNAME, :DOCNO);
  ALL_OK=1;
  suspend;
end^

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

[kdv]

SELECT MAX(ID) конечно, многим поможет

[voltron]

Код вставки оказался не столь и страшным. Я сделал хранимые процедуры для вставки всех нужных видов записей.

Пошел по такому же пути - вставка выполняется посредством хранимой процедуры.
Что-то не совсем понял по MAX(ID) - у вас что всегда право цепляется к последнему участку?
P.S.Участки, права... Вы случаем с кадастром не связанны? Коллега?

[KKomov]

Код вставки оказался не столь и страшным. Я сделал хранимые процедуры для вставки всех нужных видов записей.

Пошел по такому же пути - вставка выполняется посредством хранимой процедуры.
Что-то не совсем понял по MAX(ID) - у вас что всегда право цепляется к последнему участку?

Да. Такова узкая задача - импорт данных из XML. Там данные именно в таком порядке, поэтому можно было так вставлять.

P.S.Участки, права... Вы случаем с кадастром не связанны? Коллега?

Данные в том XML-файле были именно кадастровые. Так что можно наверно и так сказать.