Hauptmenü

Untermenü

Advanced SQL - Einstiegstutorial 2 - Referentielle Integrität

1. Die Abschnitte

2. Der Sinn und Zweck

... der vorherigen Abschnitte kommt eigentlich erst hier richtig zum Tragen. Denn jetzt spielen wir mal ein paar Aktionen durch und schauen uns das Ergebnis an. Und darum werden wir ein paar Datensätze in die ewigen Jagdgründe befördern und schauen, was passiert.

3. ON DELETE RESTRICT

Dazu konzentrieren wir uns auf die Tabellen wesen und charakter. Denn in letzterer Tabelle haben wir folgende Relation erstellt.


FOREIGN KEY (wesenREFERENCES wesen(id)
  
ON DELETE RESTRICT

Jetzt lassen wir mal ein delete from wesen where id = 4; auf die Datenbank los. Und was passiert? Wir bekommen je nach Frontend eine Meldung à la SQL Error (1451): cannot delete or update a parent row: a foreign key contraint fails (...).

Merke!

Man kann keinen Datensatz aus einer "Elterntabelle" löschen, wenn es einen "verlinkten" Eintrag in der "Kindtabelle" gibt.

4. ON DELETE SET NULL

Das haben wir nur an einer Stelle gesetzt. Nämlich in der Tabelle mitglied.


FOREIGN KEY (gildeREFERENCES gilde(id)
  
ON DELETE SET NULL

Wenn wir jetzt also in der Tabelle gilde zum Beispiel den ersten Eintrag mit delete from gilde where id = 1; löschen, so wird in der Tabelle mitglied die Spalte gilde bei den ersten beiden Mitgliedern auf NULL gesetzt.

5. ON DELETE CASCADE

Wie der Name schon sagt, kann man damit eine regelrechte Kaskade an Reaktionen auslösen. Und darum wollen wir jetzt einen Datensatz aus der Tabelle charakter löschen. Vorab vergegenwärtigen wir uns noch mal die Beziehungen der betroffenen Tabellen zueinander.

mitglied

Hier gibt es einen Fremdschlüssel auf die Tabelle charakter.


FOREIGN KEY (charakterREFERENCES charakter(id)
  
ON DELETE CASCADE ON UPDATE CASCADE,

markt

In dieser Tabelle haben wir zwei(!) Fremdschlüssel, die auf die Tabelle mitglied verweisen.


FOREIGN KEY (mitgliedREFERENCES mitglied(id)
  
ON DELETE CASCADE ...
FOREIGN KEY (besitzerREFERENCES mitglied(id)
  
ON DELETE CASCADE ...

angebot

Bei dieser Tabelle existieren sogar drei Relationen zur Tabelle mitglied.


FOREIGN KEY (vonREFERENCES mitglied(id)
  
ON DELETE CASCADE ...
FOREIGN KEY (anREFERENCES mitglied(id)
  
ON DELETE CASCADE ...
FOREIGN KEY (fuerREFERENCES mitglied(id)
  
ON DELETE CASCADE ...

tausch

Hier haben wir eine Fremdschlüssel-Beziehung zur Tabelle angebot und eine zu mitglied.


FOREIGN KEY (angebotREFERENCES angebot(id)
  
ON DELETE CASCADE ...
FOREIGN KEY (mitgliedREFERENCES mitglied(id)
  
ON DELETE CASCADE ...

Und jetzt

... löschen wir einfach mal einen Datensatz aus der Tabelle charakter. Zum Beispiel mit einem DELETE FROM charakter WHERE id = 2. Wenn man sich nun durch die Tabellen mitglied, markt, angebot und tausch hangelt, dann sieht man, dass auf einmal überall ein Datensatz fehlt.

Ihr seht also, dass man bei einem ON DELETE CASCADE eine regelrechte Kettenreaktion auslösen kann. Und das macht die Sache ein wenig heikel, da man bei großen Datenbanken mit zig Tabellen irgendwann mal den Überblick verliert.

6. ON UPDATE CASCADE

Das ist eine ganz einfache Sache. Ändert mal den PRIMARY KEY in irgendwelchen "Elterntabellen" und schaut euch dann die "Kindtabellen" an. Dort wurde der Fremdschlüssel automatisch angepasst. Als Beispiel nehmen wir einfach mal die Tabelle und machen per UPDATE mitglied SET id = 100 WHERE id = 1; aus der 1 in der Spalte id ein 100.

Und dann schaut mal in den Tabellen markt, angebot und tausch. Dann seht ihr, dass dort überall der Fremdschlüssel angepasst worden ist. Praktisch, gelle?

zurück zum vorherigen Abschnitt weiter zum nächsten Abschnitt