Referentielle Integrität – was passiert beim Löschen, wenn Fremdschlüssel dranhängen?

Genau richtig gedacht 🙂 Referentielle Integrität heißt: Ein Fremdschlüssel darf nur auf einen Wert zeigen, der in der referenzierten Tabelle tatsächlich existiert (oder auf NULL, wenn erlaubt). Die Datenbank verhindert dadurch „verwaiste“ Zeilen – z. B. eine Bestellung, die auf einen Kunden verweist, den es gar nicht mehr gibt.

Was beim Löschen des referenzierten Datensatzes passiert, legst du mit der ON DELETE-Regel fest:

• RESTRICT / NO ACTION: Das Löschen wird verweigert, solange noch Kind-Zeilen dranhängen. Der sicherste Default – du musst erst die abhängigen Zeilen aufräumen.
• CASCADE: Die Kind-Zeilen werden automatisch mitgelöscht. Praktisch, aber gefährlich – ein gelöschter Kunde reißt alle seine Bestellungen mit.
• SET NULL: Der Fremdschlüssel in den Kind-Zeilen wird auf NULL gesetzt (setzt voraus, dass die Spalte NULL erlaubt).

Daniels Aufzählung ist komplett – ich geb dir noch die Praxis-Faustregel dazu, wann man was nimmt:

• CASCADE bei einer echten „gehört-zu“-Beziehung, wo das Kind ohne den Elternteil sinnlos ist – klassisch Rechnung → Rechnungspositionen. Löschst du die Rechnung, sollen die Positionen mitgehen.
• RESTRICT, wenn die Kind-Daten eigenständigen Wert haben und nicht versehentlich verschwinden dürfen – z. B. Kunde → Bestellungen. Da willst du eher gewarnt werden.
• SET NULL, wenn die Beziehung optional ist – z. B. Mitarbeiter → Abteilung: Wird die Abteilung aufgelöst, bleibt der Mitarbeiter bestehen, nur ohne Abteilung.

Und zur Sicherheit: Es gibt dieselben Regeln auch als ON UPDATE für den Fall, dass sich der Schlüsselwert selbst ändert. In der Praxis nimmt man aber besser unveränderliche Schlüssel (z. B. eine ID), dann spielt ON UPDATE kaum eine Rolle.