nicht angemeldet
Hallo,
Nochmals: Der FOREIGN-KEY-CONSTRAINT mit ON UPDATE behandelt genau den Fall, dass in der Parenttabelle ein Primärschlüsselwert geändert wird, für den es Verweise in der Childtabelle gibt. Wenn Du das zulässt und in der Childtabelle nichts änderst, dann hast Du in der Childtabelle (mindestens) einen verwaisten Eintrag, d.h. zu dem Wert in der Fremdschlüsselspalte gibt es keinen passenden Wert in der Primärschlüsselspalte der referenzierten Tabelle. Genau der gleiche Effekt, als wäre der entsprechende Eintrag in der referenzierten Tabelle gelöscht worden.
Ok, alles klar. Ich dachte zuerst, ich hätte vielleicht irgend eine Möglichkeit, UPDATEs auf diese Weise zu vereinfachen.
Übrigens schreibt mir Erwin die UPDATE-Constraints gar nicht ins SQL-Script:
p_k_kunde SERIAL NOT NULL,
p_produktbezeichnung VARCHAR(20) NOT NULL,
p_preis FLOAT(2) NOT NULL
);
CREATE UNIQUE INDEX XPKPreis
ON Preis
(
p_id
);
CREATE TABLE Preiskategorie
(pk_id CHAR NOT NULL,
pk_bezeichnung VARCHAR(20) NOT NULL
);
CREATE UNIQUE INDEX XPKPreiskategorie
ON Preiskategorie
(
pk_id
);
ALTER TABLE Kunde
ADD PRIMARY KEY (k_id)
;
ALTER TABLE Preis
ADD PRIMARY KEY (p_id)
;
ALTER TABLE Preiskategorie
ADD PRIMARY KEY (pk_id)
;
ALTER TABLE Preis
ADD CONSTRAINT kategorie_kunde FOREIGN KEY (p_pk_preiskategorie)
REFERENCES Preiskategorie
ON DELETE SET NULL
;
ALTER TABLE Preis
ADD CONSTRAINT preis_kunde FOREIGN KEY (p_k_kunde)
REFERENCES Kunde
ON DELETE CASCADE
;
Es ist aber eh besser so. Es hat ja m.M.n. auch keinen Sinn, ein Konzept zu entwickeln, wo inkonsistente Daten entstehen könnten.
Markus
