Rdb$foreign1

Rdb$foreign1

Rdb$foreign1 : Multi-millones de consejos para hacer su vida mas facil.

Interbase genera muy hostil nombres para las restricciones. Este es un script que va a hacer es generar mas amable.

/*

SUGERENCIA ACERCA DE COMO CONTROLAR LOS NOMBRES DE
INDICES CAUSANTES de CLAVES principales Y externas

ALGUNOS COMENTARIOS ACERCA de ESTA secuencia de COMANDOS:
================================

Interbase (aqui: IB5.x en Wintel) genera un indice cada vez que usted
declarar una primaria o clave externa de una tabla. El pk o fk es un
restriccion que se le puede dar un nombre, pero el indice generado siempre
valor por defecto un nombre como 'RDB$PRIMARYnn' respectivamente 'RDB$FOREIGNnn'
donde nn es un numero que esta dado por un sistema generador. La definicion de un
nombre diferente no es ofrecido por DDL lo que es realmente lamentable.

El pk/fk restricciones se almacenan en la RDB$RELATION_CONSTRAINTS sistema
tabla. En la RDB$CONSTRAINT_NAME columna encontramos el nombre de la restriccion de
el fk/pk y la RDB$INDEX_NAME columna almacena el nombre del indice del IB
genera para usted. Los datos sobre los indices se almacenan en RDB$INDICES y
RDB$INDEX_SEGMENTS tablas. Cuando no hay registro en RDB$RELATION_CONSTRAINTS
hace referencia a un indice que puede actualizar este indice de los registros de RDB$INDICES
y RDB$INDEX_SEGMENTS e incluso cambiar el nombre del indice de esta manera (por ejemplo, para
el usuario declara indices). Para los indices que se utilizan para una relacion
restriccion esto se consigue mediante un sistema de gatillo. En el otro lado
actualizacion de RDB$RELATION_CONSTRAINTS parece ser generalmente prohibido.

Para romper estos limites declaro adicionales antes de desencadenador de insercion en
RDB$RELATION_CONSTRAINTS donde puedo modificar el nombre de indice predeterminado y
cambiar a una concatenacion de el prefijo 'IDX_' y el nombre de la
subyacente ref. la restriccion. Nombre Original y sustituir el nombre de
se almacena temporalmente en la tabla 'hacked_indexnames'. El gatillo es
despedido por ejemplo cuando se crea una tabla que contiene una primaria o extranjeros
restriccion de clave. Despues de esto ha de suceder a la RDB$RELATION_CONSTRAINTS tabla
tiene un registro nuevo con mi 'IDX_xxxx' nombre de la RDB$INDEX_NAME columna.
(Nota de que el nombre de la restriccion no debe ser mas largo que 31-4=27 caracteres!)
En este momento este es un incoherente situacion, porque el indice
sin embargo, ha sido almacenado bajo el nombre predeterminado en RDB$INDICES y
RDB$INDEX_SEGMENTS y asi el nuevo registro en RDB$RELATION_CONSTRAINTS
puntos a un indice que no existe. Sin embargo, esta situacion me permite
modificar los registros nuevos en RDB$INDICES y RDB$INDEX_SEGMENTS, lo que es
hecho por mi procedimiento almacenado 'apply_indexnames'. Usted tiene que ejecutar este
procedimiento cada vez despues de que hayas creado una tabla o creado relacion
limitaciones de una manera diferente. La confirmacion antes y despues de la ejecucion de
'apply_indexnames' parece ser necesario porque el Interbase kernel
(¿ los hay?) parece tener su propio punto de vista a las tablas del sistema.

La secuencia de comandos siguiente demonstates este 'hack'.

Ejecutar y probar, por ejemplo 'PLAN de ajuste' y 'SELECT * FROM pedidos POR
a1' y se obtiene

PLAN (UN FIN de IDX_PK_A)

en lugar de 'PLAN (UN FIN de RDB$PRIMARY1)'

puede utilizar el robo de nombres de indice en el PLAN de clausulas. La validacion de la
base de datos de informa de ningun error y el robo de nombres de indice de sobrevivir incluso a un
g'backup/resorte. De todos modos, por supuesto, NO voy a decir que ESTA ES UNA MANERA SEGURA DE
IR ni yo recomiendo usarlo. Este es solo un ejemplo que viene de lo que usted puede
¿en usted. Sientase libre de usarlo en un 'AS_IS'.

Sus Comentarios son bienvenidos.

Karsten Strobel
AIT GmbH, Augsburgo
Alemania
(03-AGO-1998)

correo electronico: [email protected]

28-OCT-1999:
Prueba con IB5.6 (Wintel), todavia funciona muy bien

*/

CREAR BASE de datos 'C:/TEMP/TEST.GDB' USUARIO 'SYSDBA' CONTRASEÑA 'llave maestra'

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

ESTABLECER el TERMINO ^

CREATE TRIGGER rel_constr_bi PARA RDB$RELATION_CONSTRAINTS ANTES de INSERTAR
DECLARAR la VARIABLE new_idx_name VARCHAR(31)
BEGIN
& nbsp & nbsp IF (NUEVO.RDB$INDEX_NAME NO ES NULL Y
& nbsp & nbsp & nbsp & nbsp & nbsp & nbsp NUEVO.RDB$CONSTRAINT_TYPE ('PRIMARY KEY','FOREIGN KEY')) THEN
& nbsp & nbsp EMPEZAR
& nbsp & nbsp & nbsp & nbsp new_idx_name = 'IDX_'||NUEVO.RDB$CONSTRAINT_NAME /* Esto se producira si mas de 31 caracteres !!! */
& nbsp & nbsp & nbsp & nbsp INSERTAR EN hacked_indexnames VALORES (NUEVO.RDB$INDEX_NAME :new_idx_name)
& nbsp & nbsp & nbsp & nbsp NUEVO.RDB$INDEX_NAME = new_idx_name
& nbsp & nbsp FINAL
FIN
^

CREATE PROCEDURE apply_indexnames COMO
DECLARAR la VARIABLE old_idx_name VARCHAR(31)
DECLARAR la VARIABLE new_idx_name VARCHAR(31)
BEGIN
& nbsp & nbsp
& nbsp & nbsp & nbsp & nbsp SELECCIONE old_name, new_name DE hacked_indexnames
& nbsp & nbsp & nbsp & nbsp EN :old_idx_name, :new_idx_name
& nbsp & nbsp HACER
& nbsp & nbsp EMPEZAR
& nbsp & nbsp & nbsp & nbsp ACTUALIZACION RDB$INDEX_SEGMENTS CONJUNTO de RDB$INDEX_NAME = :new_idx_name DONDE RDB$INDEX_NAME = :old_idx_name
& nbsp & nbsp & nbsp & nbsp ACTUALIZACION RDB$INDICES CONJUNTO de RDB$FOREIGN_KEY = :new_idx_name DONDE RDB$FOREIGN_KEY = :old_idx_name
& nbsp & nbsp & nbsp & nbsp ACTUALIZACION RDB$INDICES CONJUNTO de RDB$INDEX_NAME = :new_idx_name DONDE RDB$INDEX_NAME = :old_idx_name
& nbsp & nbsp FINAL
& nbsp & nbsp ELIMINAR DE hacked_indexnames
FIN
^

ESTABLECER el TERMINO ^

CREAR una TABLA (a1 INTEGER not NULL CONSTRAINT pk_a CLAVE PRINCIPAL,
a2 ENTERO)

COMMIT
la EJECUCION del PROCEDIMIENTO apply_indexnames
COMMIT

CREAR TABLA b (b1 INTEGER not NULL CONSTRAINT pk_b CLAVE PRINCIPAL,
b2 ENTERO RESTRICCION fk_b2_a REFERENCIAS a (a1))

COMMIT
la EJECUCION del PROCEDIMIENTO apply_indexnames
COMMIT

ALTER TRIGGER rel_constr_bi INACTIVO

COMMIT