Wenn die Datenbank Nein sagt

Mehrmals in dieser Lektion hat die Datenbank eine Änderung abgelehnt. Solche Fehler kommen von Constraints (Einschränkungen): Regeln, die eine Tabelle für ihre Daten aufstellt. Die Datenbank prüft sie bei jedem INSERT und UPDATE (und die Fremdschlüssel auch bei jedem DELETE), und wenn eine Anweisung eine von ihnen verletzen würde, lehnt sie die ganze Anweisung ab und ändert nichts. Die Regeln sind Teil der Datenbank, also schützen sie die Daten, egal wer sie schreibt: die Website des Shops, seine Lager-App oder du.

Das sind die Constraints von Pixel Shop, jeweils mit einem Beispiel für ihre Meldung:

• NOT NULL: Die Spalte muss einen Wert haben. In Pixel Shop dürfen nur das Erscheinungsdatum eines Spiels, die Stadt und der Werber eines Kunden und der Kommentar einer Bewertung leer sein. Ein Spiel ohne Altersfreigabe bekommt NOT NULL constraint failed: spiele.altersfreigabe.
• UNIQUE: Keine zwei Zeilen dürfen denselben Wert in der Spalte haben. Jeder Kunde hat eine eigene E-Mail-Adresse, also bekommt ein zweiter Kunde mit emma.becker@mail.de die Meldung UNIQUE constraint failed: kunden.email. Auch ein Primärschlüssel ist eindeutig: Eine ID, die schon vergeben ist, bekommt UNIQUE constraint failed: spiele.id, und da der Primärschlüssel einer Bewertung aus Spiel und Kunde zusammen besteht, kann jeder Kunde jedes Spiel nur einmal bewerten.
• CHECK: eine Bedingung, die jede Zeile erfüllen muss. In Pixel Shop: Sterne von 1 bis 5, eine Menge größer als 0 und der Status bezahlt oder erstattet. Die Meldung zeigt die Bedingung: CHECK constraint failed: sterne BETWEEN 1 AND 5.
• FOREIGN KEY: Ein Fremdschlüssel muss auf eine Zeile zeigen, die es gibt. Eine Bewertung von Kunde 99 bekommt FOREIGN KEY constraint failed, ebenso das Löschen einer Zeile, auf die andere Zeilen zeigen. Diese Meldung sagt nicht, um welche Spalte es geht.
• Typen: In STRICT-Tabellen nimmt eine INTEGER-Spalte nur Ganzzahlen auf und eine TEXT-Spalte nur Text. Text in einer Zahlenspalte bekommt cannot store TEXT value in INTEGER column bewertungen.sterne. Eine Ganzzahl in Anführungszeichen, wie '5', wird ohne Probleme in die Zahl 5 umgewandelt, aber 'fünf' oder 4.5 werden abgelehnt.

Wenn mehrere Zeilen auf einmal hinzugefügt werden und eine davon eine Regel verletzt, kommt keine von ihnen hinein:

INSERT INTO bewertungen (spiel_id, kunde_id, sterne)
VALUES
    (4, 4, 5),
    (14, 2, 6);

Error on line 1: CHECK constraint failed: sterne BETWEEN 1 AND 5

Die erste Bewertung ist in Ordnung, aber die zweite hat 6 Sterne, also lehnt die Datenbank die ganze Anweisung ab, und die erste Bewertung wird ebenfalls nicht hinzugefügt.

Wenn eine Anweisung mehr als eine Regel verletzt, nennt dir die Datenbank nur eine davon. Behebe sie und führe die Anweisung erneut aus, und du bekommst vielleicht die nächste. Die Tabelle und die Spalte in der Meldung zeigen dir, wo du suchen musst. Und woher kommen die Regeln? Jede Tabelle hat sie in ihrer Definition, der Anweisung CREATE TABLE, die sie erstellt hat. In der nächsten Lektion schreibst du deine eigenen Tabellen, samt Constraints.

Typischer Fehler: den Fehler aus dem Weg räumen, statt die Daten zu korrigieren. Wenn eine neue Kundin UNIQUE constraint failed: kunden.email bekommt, besteht die Lösung nicht darin, einen Buchstaben der E-Mail-Adresse zu ändern, bis die Datenbank sie annimmt. Vielleicht steht die Kundin schon in der Tabelle, oder die E-Mail-Adresse ist falsch. Der Constraint hat ein echtes Problem gefunden, also finde heraus, welches.