RDB$ foreign1

RDB$ foreign1

RDB$ foreign1 : Mehreren tausend Tipps, um Ihr Leben einfacher machen.

InterBase generiert sehr unfreundliche Namen für Einschränkungen. Dies ist ein Skript, die es mehr freundlichen diejenigen generieren machen wird.

/*

ANREGUNG ZUM STEUERN DER NAMEN DER
INDIZES DIESER UNTERLIEGEN PRIMÄR- UND FREMDSCHLÜSSEL-SCHLÜSSEL

EINIGE KOMMENTARE ZU DIESEM SKRIPT:
================================

InterBase (hier: IB5.x auf Wintel) erzeugt einen Index jedes Mal Sie
Deklarieren Sie einen primären oder fremden Schlüssel für eine Tabelle. Der Pk oder Fk ist ein
Einschränkung, die einen Namen, aber immer die generierte Index gegeben werden kann
Standardwert ist ein Name wie 'RDB$ PRIMARYnn' bzw. 'RDB$ FOREIGNnn'
Nn ist eine Zahl, die von einem Generator System gegeben ist. Definieren einer
anderen Namen ist nicht von DDL angeboten, was wirklich bedauerlich ist.

Die Pk/Fk-Einschränkungen sind im RDB$ RELATION_CONSTRAINTS System gespeichert.
Tabelle. In der RDB$ CONSTRAINT_NAME Spalte finden Sie den Namen der Einschränkung der
der Fk/Pk und die RDB$ INDEX_NAME Spalte speichert den Namen des Index IB
generiert für Sie. Daten über die Indizes werden in RDB$ INDICES und
RDB$ INDEX_SEGMENTS Tabellen. Wenn kein Datensatz in der RDB$ RELATION_CONSTRAINTS
verweist einen Index können Sie diese Indexeinträge in RDB$ Indizes aktualisieren
und RDB$ INDEX_SEGMENTS und sogar ändern eines Indexes nennen diese Weise (z. B. für
Benutzer deklarierten Indizes). Für Indizes, die für eine Beziehung verwendet werden
Einschränkung, die dies durch einen Systemtrigger verhindert wird. Andererseits
die Aktualisierung der RDB$ RELATION_CONSTRAINTS scheint generell verboten werden.

Diese Grenzen zu brechen, die, denen ich auf einen zusätzliche vor-Insert-Trigger deklarieren
RDB$ RELATION_CONSTRAINTS wo ich den Index Standardnamen ändern und
Ändern Sie ihn auf eine Verkettung aus dem Präfix 'IDX_' und den Namen der
zugrunde liegenden Ref. Einschränkung. Originalnamen und substituierte Namen sind
vorübergehend in der Tabelle 'Hacked_indexnames' gespeichert. Der Auslöser ist
ausgelöst wird, wenn z.B. eine Tabelle erstellt wird, die eine primäre oder ausländische enthält
Key-Einschränkung. Danach hat die RDB$ RELATION_CONSTRAINTS Tabelle geschehen
die RDB$ INDEX_NAME Spalte hat einen neuen Rekord mit meinem Namen 'IDX_xxxx'.
(Beachten Sie, dass der Einschränkungsname nicht länger als 31-4 sein muss = 27 Zeichen!)
Im Moment ist dies eine uneinheitliche Situation, weil der Index
Dennoch es ist Standardnamen RDB$ Indices gespeichert wurden und
RDB$ INDEX_SEGMENTS und so den neuen Datensatz im RDB$ RELATION_CONSTRAINTS
Punkte auf einen Index, der nicht existiert. Doch ermöglicht diese Situation mir
Ändern Sie die neue Datensätze in die RDB$ Indizes und RDB$ INDEX_SEGMENTS, was ist
durch meine gespeicherte Prozedur 'Apply_indexnames' durchgeführt. Sie müssen dies ausführen
Verfahren, jedes Mal, nachdem Sie eine Tabelle erstellt oder Beziehung erstellt haben
Einschränkungen auf eine andere Weise. Vor einer nach Ausführung der COMMIT
'Apply_indexnames' scheint notwendig zu sein weil die Interbase Kernel
(tut solche gibt es?) eigene Ansicht der Systemtabellen zu haben scheint.

Das Skript unten veranschaulicht diesen 'Hack'.

Führen Sie es und versuchen Sie zum Beispiel, 'SET-PLAN' und 'wählen Sie * aus ein ORDER BY
a1;'und Sie erhalten

PLAN (EINE ORDER-IDX_PK_A)

anstatt 'PLAN (eine Bestellung RDB$ Primär1)'

Sie können die zerhackte Indexnamen in PLAN-Klauseln verwenden. Validierung der
Datenbank-Berichte keine Fehler und die zerhackte Indexnamen sogar überleben eine
g'backup/Resorte. Wie auch immer, kann natürlich ich nicht Anspruch dieser ist A sichere Art und Weise zu
GEHEN noch tun ich empfehlen, es zu benutzen. Dies ist nur ein Beispiel, das kommt von dem, was Sie können
auf Sie zu tun. Zögern Sie nicht, es auf Basis des 'AS_IS' zu benutzen.

Ihr Feedback ist willkommen.

Karsten Strobel
AIT GmbH - Augsburg
Deutschland
(3. AUGUST 1998)

e-Mail: [email protected]

28. OKTOBER 1999:
Getestet mit IB5.6 (Wintel), noch funktioniert gut

*/

ERSTELLEN DER DATENBANK 'C:\TEMP\TEST. GDB'Benutzer'SYSDBA'Kennwort'Masterkey';

CREATE TABLE Hacked_indexnames (Old_name VARCHAR(31), New_name VARCHAR(31));

SET-BEGRIFF ^;

CREATE TRIGGER Rel_constr_bi für RDB$ RELATION_CONSTRAINTS vor INSERT AS
VARIABLE deklarieren New_idx_name VARCHAR(31);
BEGIN
IF (NEU. RDB$ INDEX_NAME IST NICHT NULL UND
Neu. RDB$ CONSTRAINT_TYPE ('SCHLÜSSEL','AUSLÄNDISCHE PRIMÄRSCHLÜSSEL')) DANN
BEGIN
New_idx_name = 'IDX_' || Neu. RDB$ CONSTRAINT_NAME; / * Dies schlägt fehl, wenn länger als 31 Zeichen!!! */
INSERT INTO Hacked_indexnames VALUES (neu. RDB$ INDEX_NAME,: New_idx_name);
Neu. RDB$ INDEX_NAME = New_idx_name;
ENDE
ENDE
^

CREATE PROCEDURE Apply_indexnames als
VARIABLE deklarieren Old_idx_name VARCHAR(31);
VARIABLE deklarieren New_idx_name VARCHAR(31);
BEGIN
FÜR
Wählen SIE Old_name, New_name FROM hacked_indexnames
IN: Old_idx_name,: New_idx_name
TUN
BEGIN
RDB$ UPDATE INDEX_SEGMENTS SET RDB$ INDEX_NAME =: New_idx_name wo RDB$ INDEX_NAME =: Old_idx_name;
UPDATE RDB$ Indizes legen RDB$ FOREIGN_KEY =: New_idx_name wo RDB$ FOREIGN_KEY =: Old_idx_name;
UPDATE RDB$ Indizes legen RDB$ INDEX_NAME =: New_idx_name wo RDB$ INDEX_NAME =: Old_idx_name;
ENDE
DELETE FROM Hacked_indexnames;
ENDE
^

SET-BEGRIFF; ^

Erstellen Sie Tabelle ein (a1-Ganzzahl nicht NULL-Einschränkung Pk_a PRIMARY KEY
a2-INTEGER);

COMMIT;
EXECUTE PROCEDURE Apply_indexnames;
COMMIT;

CREATE TABLE b (b1 INTEGER nicht NULL-Einschränkung Pk_b PRIMARY KEY
B2 INTEGER Einschränkung fk_b2_a verweist (a1));

COMMIT;
EXECUTE PROCEDURE Apply_indexnames;
COMMIT;

ALTER TRIGGER Rel_constr_bi inaktiv;

COMMIT;