Fremdschlüssel und ON DELETE CASCADE in SQLite

In meinen Projekten läuft die Datenbank fast immer auf SQLite. Ein Detail, das dort gern übersehen wird: Fremdschlüssel-Prüfungen sind standardmäßig aus. Wer sie will (und das solltest du), muss sie pro Verbindung aktivieren.

Erst einschalten

PRAGMA foreign_keys = ON;

Das gilt pro Verbindung – setze es direkt nach dem Öffnen der Datenbank in deinem Code, nicht nur einmal in der Datei. Ohne das akzeptiert SQLite auch verwaiste Verweise klaglos.

Fremdschlüssel definieren

CREATE TABLE nutzer (
  id   INTEGER PRIMARY KEY,
  name TEXT NOT NULL
);

CREATE TABLE beitrag (
  id       INTEGER PRIMARY KEY,
  nutzer_id INTEGER NOT NULL,
  text     TEXT,
  FOREIGN KEY (nutzer_id) REFERENCES nutzer(id) ON DELETE CASCADE
);

Der Fremdschlüssel garantiert: In beitrag.nutzer_id darf nur eine existierende nutzer.id stehen. Ein Beitrag ohne gültigen Nutzer wird abgelehnt.

ON DELETE CASCADE – automatisch aufräumen

Der Zusatz ON DELETE CASCADE beantwortet die Frage „was passiert mit den Beiträgen, wenn ich einen Nutzer lösche?":

DELETE FROM nutzer WHERE id = 5;
-- alle Beiträge mit nutzer_id = 5 werden automatisch mitgelöscht

Ohne CASCADE würde SQLite das Löschen verweigern, solange noch Beiträge daran hängen (Schutz vor Datenmüll). Mit CASCADE räumt die Datenbank die abhängigen Zeilen selbst auf – kein manuelles DELETE in der richtigen Reihenfolge mehr.

Alternativen zu CASCADE

• ON DELETE SET NULL: Verweis wird auf NULL gesetzt (Beitrag bleibt, Nutzer-Bezug weg).
• ON DELETE RESTRICT (Standard): Löschen wird blockiert, solange Abhängige existieren.

Wähle bewusst: CASCADE ist bequem, aber löscht eben auch – bei wichtigen Daten ist RESTRICT oft sicherer.

Wenn du ein Projekt mit sauber modellierter, konsistenter Datenbank brauchst, baue ich dir das Fundament dahinter – meld dich über bymw.de.

Quellen

• SQLite Foreign Key Support
• PRAGMA foreign_keys – SQLite-Dokumentation