RDB $ FOREIGN1

Interbase genera molto poco per i nomi dei vincoli. Questo è uno script che renderà più facile generare quelle.

/ *

Interbase (qui: IB5.x su Wintel) genera un indice ogni volta che si
dichiarare una chiave primaria o stranieri per un tavolo. Il pk o fk è un
vincolo che può essere dato un nome, ma l'indice sempre
impostazioni predefinite per un nome come "RDB $ PRIMARYnn" rispettivamente "RDB $ FOREIGNnn"
dove nn è un numero che è dato da un sistema generatore. Definizione di un
altro nome non è offerta dal DDL che cosa è veramente deplorevole.

Il pk / fk vincoli sono memorizzati nel sistema RDB $ RELATION_CONSTRAINTS
tavolo. In RDB $ CONSTRAINT_NAME colonna si trova il nome del vincolo
il fk / pk e la RDB $ INDEX_NAME colonna memorizza il nome del indice IB
genera per voi. Dati su indici è memorizzato in RDB $ INDICI e
RDB $ INDEX_SEGMENTS tabelle. Quando non registrare in RDB $ RELATION_CONSTRAINTS
i riferimenti di un indice è possibile aggiornare i record di questo indice in RDB $ INDICI
e RDB $ INDEX_SEGMENTS e persino cambiare il nome di un indice in questo modo (ad esempio, per
utente dichiarato indici). Per gli indici che sono utilizzati per una relazione
questo vincolo è impedito da un sistema di trigger. D'altro canto
aggiornamento RDB $ RELATION_CONSTRAINTS sembra essere generalmente vietato.

Per rompere questi limiti Dichiaro un altro prima di inserire il limite
RDB $ RELATION_CONSTRAINTS dove modificare il nome e l'indice di default
cambiamento in una concatenazione di prefisso "IDX_" e il nome del
sottostanti rif. costrizione. Nome originale e sostituito nome
temporaneamente memorizzati nella tabella "hacked_indexnames". Il limite è
alimentate ad esempio, quando viene creata una tabella che contiene un primario o stranieri
vincolo di chiave. Dopo questo è avvenuto il RDB $ RELATION_CONSTRAINTS tabella
detiene un nuovo record con il mio "IDX_xxxx" nel nome RDB $ INDEX_NAME colonna.
(Si noti che il vincolo nome non deve essere superiore a 31-4 = 27 caratteri!)
In questo momento si tratta di una situazione incoerente, perché l'indice
tuttavia, è stato conservato in virtù di esso il nome predefinito in RDB $ INDICI e
RDB $ INDEX_SEGMENTS e così il nuovo record nel RDB $ RELATION_CONSTRAINTS
punta a un indice che non esiste. Tuttavia, questa situazione mi permette di
modificare il nuovo record in RDB $ INDICI e RDB $ INDEX_SEGMENTS, ciò che è
fatto dalla mia stored procedure "apply_indexnames". È necessario eseguire questa
procedura ogni volta dopo che hai creato una tabella o un rapporto creato
vincoli in modo diverso. L'impegno, prima di eseguire uno dopo
"apply_indexnames" sembra essere necessario in quanto il kernel Interbase
(non esistono?) sembra avere il proprio sistema al fine di tabelle.

Lo script demonstates sotto questo "trucco".

Esegui e cercare per esempio "SET PLAN" e "SELECT * FROM uno ORDER BY
a1, "e si ottiene

PIANO (A FINE IDX_PK_A)

piuttosto che "PIANO (A ORDINANZA RDB $ PRIMARY1)"

È possibile utilizzare l'indice nomi hacked PLAN clausole. Convalidare la
database relazioni alcun errore e la hacked indice nomi sopravvivere anche uno
g'backup / resorte. In ogni caso, ovviamente NON SI DOMANDA un modo sicuro per
GO né Consigliamo di utilizzarlo. Questo è solo un esempio di ciò che viene è possibile
fare su di voi. Sentitevi liberi di usare su un "AS_IS" base.

Il vostro feedback è il benvenuto.

Karsten Strobel
AIT GmbH - Augsburg
Germania
(03-AGO-1998)

email: strobel@ait-augsburg.de

28-OTT-1999:
Testato con IB5.6 (Wintel), ancora funziona bene

* /

CREATE DATABASE "C: \ TEMP \ TEST.GDB" utente "SYSDBA" PASSWORD "masterkey";

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

SET TERM ^;

CREATE TRIGGER rel_constr_bi RDB $ RELATION_CONSTRAINTS PER INSERIRE COME PRIMA
DECLARE VARIABLE new_idx_name VARCHAR (31);
BEGIN
SE (NEW.RDB $ INDEX_NAME NON E NULL
NEW.RDB $ CONSTRAINT_TYPE IN ( "chiave primaria", "FOREIGN KEY")) THEN
BEGIN
new_idx_name = "IDX_" | | NEW.RDB $ CONSTRAINT_NAME; / * Questo non andrà a buon fine se più di 31 caratteri! * /
INSERT INTO hacked_indexnames VALUES (NEW.RDB $ INDEX_NAME,: new_idx_name);
NEW.RDB $ INDEX_NAME = new_idx_name;
FINE
FINE
^

CREATE PROCEDURE apply_indexnames AS
DECLARE VARIABLE old_idx_name VARCHAR (31);
DECLARE VARIABLE new_idx_name VARCHAR (31);
BEGIN
PER
SELECT old_name, new_name DA hacked_indexnames
IN: old_idx_name,: new_idx_name
DO
BEGIN
AGGIORNAMENTO RDB $ INDEX_SEGMENTS SET RDB $ = INDEX_NAME: DOVE new_idx_name RDB $ = INDEX_NAME: old_idx_name;
AGGIORNAMENTO RDB INDICI SET RDB $ $ = FOREIGN_KEY: DOVE new_idx_name RDB $ = FOREIGN_KEY: old_idx_name;
AGGIORNAMENTO RDB INDICI SET RDB $ $ = INDEX_NAME: DOVE new_idx_name RDB $ = INDEX_NAME: old_idx_name;
FINE
DELETE FROM hacked_indexnames;
FINE
^

SET TERM; ^

CREATE TABLE uno (a1 INTEGER NOT NULL VINCOLO pk_a PRIMARY KEY,
INTEGER a2);

COMMIT;
EXECUTE PROCEDURA apply_indexnames;
COMMIT;

CREATE TABLE b (b1 INTEGER NOT NULL VINCOLO pk_b PRIMARY KEY,
b2 INTEGER fk_b2_a VINCOLO RIFERIMENTI uno (a1));

COMMIT;
EXECUTE PROCEDURA apply_indexnames;
COMMIT;

ALTER TRIGGER rel_constr_bi INACTIVE;

COMMIT;