RDB $ FOREIGN1

Interbase gera muito hostil nomes de constrangimentos. Este é um script que irá torná-lo mais amigável gerar queridos.

/ *

Interbase (aqui: IB5.x sobre Wintel) gera um índice a cada vez que você
Declaro primária ou uma chave estrangeira para uma tabela. O pk ou é um fk
constrangimento que possa ser dado um nome, mas o índice gerado semper
padrão para um nome como "RDB $ PRIMARYnn", respectivamente "RDB $ FOREIGNnn"
onde nn é um número que é dado por um sistema gerador. Definindo um
outro nome não é oferecido por DDL o que é verdadeiramente lamentável.

O pk / fk constrangimentos são armazenados no sistema RDB $ RELATION_CONSTRAINTS
mesa. No RDB $ CONSTRAINT_NAME coluna você encontrará o nome do constrangimento
o fc / pk e os RDB $ INDEX_NAME coluna armazena o nome do índice IB
gera para você. Os dados sobre os índices são armazenados em RDB $ ÍNDICES e
RDB $ INDEX_SEGMENTS tabelas. Quando nenhum registro na RDB $ RELATION_CONSTRAINTS
referências um índice que você pode atualizar este índice de registros na RDB $ ÍNDICES
e RDB $ INDEX_SEGMENTS e até mesmo alterar um nome de índice dessa maneira (por exemplo, para
utilizador índices declarados). Para os índices que são utilizados para uma relação
este condicionalismo é impedido por um sistema de gatilho. Por outro lado
atualizando RDB $ RELATION_CONSTRAINTS parece ser geralmente proibido.

Para romper estes limites Dou um adicional antes de inserir-disparador em
RDB $ RELATION_CONSTRAINTS onde eu modificar o nome eo índice padrão
alterá-lo para uma concatenação do prefixo "IDX_" eo nome do
subjacentes ref. constrangimento. Nome original eo nome são substituídos
temporariamente armazenados na tabela "hacked_indexnames". O gatilho é
despedido por exemplo, quando é criada uma tabela que contém uma primária ou estrangeira
chave constrangimento. Depois disto acontecer tem a tabela RDB $ RELATION_CONSTRAINTS
detenha um novo recorde com a minha "IDX_xxxx" em nome do RDB $ INDEX_NAME coluna.
(Note que o constrangimento nome não deve ser mais longo do que 31-4 = 27 caracteres!)
Neste momento esta é uma situação incoerente, pois o índice
no entanto tem sido armazenado ao abrigo do mesmo padrão do nome e do RDB $ ÍNDICES
RDB $ INDEX_SEGMENTS e assim o novo recorde na RDB $ RELATION_CONSTRAINTS
aponta para um índice que não existe. Ora esta situação permite-me que
modificar os novos registros na RDB $ ÍNDICES e RDB $ INDEX_SEGMENTS, o que é
feito pela minha stored procedure "apply_indexnames". Você tem que executar esse
procedimento cada vez depois de você ter criado uma mesa ou criados relação
condicionalismos de uma forma diferente. O COMMIT antes após executar uma
"apply_indexnames" afigura-se necessária porque o kernel Interbase
(não existe tal?) parece ter a sua própria visão para o sistema de tabelas.

O script abaixo demonstates este "hack".

Executá-la e tentar, por exemplo "PLANO SET;" e "SELECT * FROM uma ORDER BY
a1; "e você obterá

PLANO (A ORDEM IDX_PK_A)

em vez de "PLANO (A ORDEM RDB $ PRIMARY1)"

Você pode usar o índice cortada em nomes PLANO cláusulas. Validando o
relatórios de dados sem erro e os nomes cortada mesmo sobreviver a um índice
g'backup / resorte. De qualquer maneira, é claro que eu não reclamam esta é uma forma segura de
GO recommand nem posso usá-lo. Este é apenas um exemplo que vem do que você pode
fazer com você. Sinta-se livre para usá-la em um "AS_IS" base.

Seu feedback é bem-vinda.

Karsten Strobel
AIT GmbH - Augsburg
Alemanha
(03-AUG-1998)

email: strobel@ait-augsburg.de

28-OCT-1999:
Testado com IB5.6 (Wintel), ainda funciona perfeitamente

* /

CREATE DATABASE "C: \ TEMP \ TEST.GDB" USER "SYSDBA" SENHA "masterkey";

CREATE TABLE hacked_indexnames (old_name VARCHAR (31), new_name VARCHAR (31));

SET TERM ^;

Gatilho para criar rel_constr_bi RDB $ RELATION_CONSTRAINTS antes de inserir como
DECLARO VARIÁVEL new_idx_name VARCHAR (31);
BEGIN
If (NEW.RDB $ INDEX_NAME não é nulo e
NEW.RDB $ CONSTRAINT_TYPE IN ( "PRIMARY KEY", "FOREIGN KEY")) THEN
BEGIN
new_idx_name = "IDX_" | | NEW.RDB $ CONSTRAINT_NAME; / * Isto irá falhar se mais de 31 caracteres! * /
INSERT INTO hacked_indexnames VALUES (NEW.RDB $ INDEX_NAME,: new_idx_name);
NEW.RDB $ INDEX_NAME = new_idx_name;
FIM
FIM
^

Como criar procedimento apply_indexnames
DECLARO VARIÁVEL old_idx_name VARCHAR (31);
DECLARO VARIÁVEL new_idx_name VARCHAR (31);
BEGIN
PARA
SELECT old_name, new_name DESDE hacked_indexnames
EM: old_idx_name,: new_idx_name
FAZER
BEGIN
UPDATE RDB $ INDEX_SEGMENTS SET RDB $ INDEX_NAME =: new_idx_name WHERE RDB $ INDEX_NAME =: old_idx_name;
UPDATE RDB $ ÍNDICES SET RDB $ FOREIGN_KEY =: new_idx_name WHERE RDB $ FOREIGN_KEY =: old_idx_name;
UPDATE RDB $ ÍNDICES SET RDB $ INDEX_NAME =: new_idx_name WHERE RDB $ INDEX_NAME =: old_idx_name;
FIM
DELETE FROM hacked_indexnames;
FIM
^

SET TERM; ^

CREATE TABLE um (a1 INTEGER NOT NULL CONSTRAINT pk_a PRIMARY KEY,
INTEGER a2);

COMMIT;
EXECUTE apply_indexnames Processual;
COMMIT;

CREATE TABLE b (b1 INTEGER NOT NULL CONSTRAINT pk_b PRIMARY KEY,
b2 INTEGER CONSTRAINT fk_b2_a um Referências (a1));

COMMIT;
EXECUTE apply_indexnames Processual;
COMMIT;

ALTER TRIGGER rel_constr_bi INATIVO;

COMMIT;