Rdb$foreign1

Rdb$foreign1

Rdb$foreign1 : Plusieurs milliers de conseils pour vous faciliter la vie.

Interbase genere tres hostile noms pour les contraintes. C'est un script qui permettra de faire generer plus respectueux.

/*

SUGGESTION SUR la FAÇON DE CONTROLER LES NOMS DE
les INDICES QUI SOUS-tendent les CLES PRIMAIRES ET ETRANGERES

QUELQUES COMMENTAIRES a PROPOS de CE SCRIPT:
================================

Interbase (ici: IB5.x sur Wintel) genere un index a chaque fois que vous
declarer un primaire ou une cle etrangere d'une table. Le pk ou fk est un
contrainte qui peut etre donne un nom, mais l'index genere toujours
par defaut, un nom comme 'RDB$PRIMARYnn', respectivement 'RDB$FOREIGNnn'
ou nn est un numero qui est donne par un systeme generateur. La definition d'un
nom different n'est pas offert en DDL, ce qui est vraiment regrettable.

Le pk/fk contraintes sont stockes dans le RDB$RELATION_CONSTRAINTS systeme
la table. Dans le RDB$colonne CONSTRAINT_NAME vous trouver le nom de la contrainte de
le fk/pk et le RDB$INDEX_NAME colonne stocke le nom de l'index de l'IB
produit pour vous. Les donnees sur les indices est stocke dans RDB$les INDICES et les
RDB$INDEX_SEGMENTS tables. Lorsqu'aucun enregistrement dans RDB$RELATION_CONSTRAINTS
reference a un indice, vous pouvez mettre a jour cet index donnees RDB$INDICES
et RDB$INDEX_SEGMENTS et meme de changer le nom de l'index de cette façon (par exemple pour
l'utilisateur declare index). Pour les index sont utilises pour une relation
contrainte c'est empechee par un systeme de declenchement. Sur l'autre main
la mise a jour de la RDB$RELATION_CONSTRAINTS semble etre generalement interdite.

Pour briser ces limites je declare supplementaires avant-declencheur d'insertion sur
RDB$RELATION_CONSTRAINTS ou j'ai modifier la valeur par defaut nom d'index et
la changer en une concatenation du prefixe 'IDX_' et le nom de la
sous-jacent ref. la contrainte. Nom d'origine et l'ont remplace par le nom de
temporairement stockes dans la table 'hacked_indexnames'. Le declencheur est
alimentees par exemple, lorsqu'un tableau est cree, qui contient une primaire ou etrangere
contrainte de cle. Apres cela a lieu le RDB$RELATION_CONSTRAINTS table
detient un nouveau record avec mon 'IDX_xxxx' nom dans le RDB$INDEX_NAME colonne.
(Notez que le nom de la contrainte ne doit pas etre plus longue que 31-4=27 caracteres!)
En ce moment, c'est une incoherence de la situation, car l'index
il a toutefois ete stockees sous son nom par defaut dans RDB$les INDICES et les
RDB$INDEX_SEGMENTS et donc le nouveau record dans RDB$RELATION_CONSTRAINTS
points d'indice qui n'existe pas. Pourtant, cette situation me permet d'
modifier les nouveaux enregistrements dans le RDB$INDICES et RDB$INDEX_SEGMENTS, qu'est-ce que
fait par ma procedure stockee 'apply_indexnames'. Vous devez executer cette
procedure a chaque fois apres que vous avez cree une table ou crees concernant
les contraintes d'une maniere differente. La validation avant un apres l'execution de
'apply_indexnames' semble necessaire parce que la Interbase noyau
(il en existe?) semble avoir son propre point de vue dans les tables systeme.

Le script ci-dessous demontre ce 'hack'.

Executer, et essayez, par exemple, 'PLAN d'ENSEMBLE' et 'SELECT * a PARTIR d'une COMMANDE PAR
a1' et vous obtenez

le PLAN de l'ORDRE IDX_PK_A)

plutot que de 'PLAN de l'ORDRE du RDB$PRIMARY1)'

Vous pouvez utiliser le pirate les noms d'index dans le PLAN de clauses. La validation de la
base de donnees des rapports d'aucune erreur et l'pirate index des noms de survivre a un
g'backup/resorte. De toute façon, bien sûr, je NE pretendons PAS que C'EST UN MOYEN SÛR DE
je ne vous recommandons de l'utiliser. C'est juste un exemple qui vient de ce que vous pouvez
ne sur vous. Se sentir libre de l'utiliser sur un 'AS_IS'.

Vos Commentaires sont les bienvenus.

Karsten Strobel
AIT GmbH Augsburg
Allemagne
(03-AOÛT-1998)

e-mail: [email protected]

28-OCT-1999:
Teste avec IB5.6 (Wintel), fonctionne toujours tres bien

*/

CREER une BASE de donnees 'C:\TEMP\TEST.GDB' UTILISATEUR 'SYSDBA' MOT de passe 'masterkey'

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

DEFINIR le TERME ^

CREATE TRIGGER rel_constr_bi POUR RDB$RELATION_CONSTRAINTS AVANT de l'INSERER en tant QUE
DECLARER la VARIABLE new_idx_name VARCHAR(31)
BEGIN
& nbsp & nbsp SI (de NOUVEAU.RDB$INDEX_NAME n'EST PAS NULL ET
& ! & ! & ! & ! & ! & nbsp NOUVELLE.RDB$CONSTRAINT_TYPE ('CLE PRIMAIRE','CLE ETRANGERE')) THEN
& nbsp & nbsp COMMENCER
& ! & ! & ! & nbsp new_idx_name = 'IDX_'||NOUVEAU.RDB$CONSTRAINT_NAME /* Ceci ne fonctionnera pas si plus de 31 caracteres !!! */
& ! & ! & ! & nbsp INSERER DANS hacked_indexnames VALEURS (de NOUVEAU.RDB$INDEX_NAME :new_idx_name)
& ! & ! & ! & nbsp NOUVELLE.RDB$INDEX_NAME = new_idx_name
& nbsp & nbsp FIN
FIN
^

CREATE PROCEDURE apply_indexnames
DECLARER la VARIABLE old_idx_name VARCHAR(31)
DECLARER la VARIABLE new_idx_name VARCHAR(31)
BEGIN
& nbsp & nbsp POUR
& ! & ! & ! & nbsp SELECTIONNEZ old_name, new_name DE hacked_indexnames
& ! & ! & ! & nbsp :old_idx_name, :new_idx_name
& nbsp & nbsp DO
& nbsp & nbsp COMMENCER
& ! & ! & ! & nbsp mise a JOUR de la RDB$INDEX_SEGMENTS ENSEMBLE RDB$INDEX_NAME = :new_idx_name OU RDB$INDEX_NAME = :old_idx_name
& ! & ! & ! & nbsp mise a JOUR de la RDB$INDICES de DEFINIR RDB$FOREIGN_KEY = :new_idx_name OU RDB$FOREIGN_KEY = :old_idx_name
& ! & ! & ! & nbsp mise a JOUR de la RDB$INDICES de DEFINIR RDB$INDEX_NAME = :new_idx_name OU RDB$INDEX_NAME = :old_idx_name
& nbsp & nbsp FIN
& nbsp & nbsp SUPPRIMER DE hacked_indexnames
FIN
^

DEFINIR le TERME ^

CREER un TABLEAU a (a1 INTEGER not NULL CONSTRAINT pk_a CLE PRIMAIRE,
a2 ENTIER)

VALIDER
EXECUTER la PROCEDURE apply_indexnames
VALIDER

CREATE TABLE b (b1 INTEGER not NULL CONSTRAINT pk_b CLE PRIMAIRE,
b2 ENTIER CONTRAINTE fk_b2_a REFERENCES (a1))

VALIDER
EXECUTER la PROCEDURE apply_indexnames
VALIDER

ALTER TRIGGER rel_constr_bi INACTIF

VALIDER