Antwort

Constraints sind Integritätsbeschränkungen, die auf Spalten oder Tabellen angewendet werden, um die Zulässigkeit von Werten automatisch zu überprüfen. Sie erlauben es:

• Daten vor falscher Eingabe zu schützen;
• Teile der Anwendungslogik in die Datenbank auszulagern (sicherer und schneller);
• Bedingungen automatisch beim Einfügen, Aktualisieren oder Löschen zu überprüfen.

Arten von grundlegenden Constraints:

• PRIMARY KEY — eindeutiger Identifikator, verbietet Duplikate und NULL.
• UNIQUE — verbietet Duplikate von Werten in einer Spalte.
• FOREIGN KEY — referentielle Integrität, Verbindung zu einer anderen Tabelle.
• CHECK — Überprüfung eines beliebigen Ausdrucks.
• NOT NULL — Verbot von NULL-Werten in der Spalte.

Beispiel:

CREATE TABLE orders (
  id SERIAL PRIMARY KEY,
  user_id INT REFERENCES users(id), -- foreign key
  price DECIMAL(10,2) CHECK (price > 0),
  created_at TIMESTAMP NOT NULL
);

Fangfrage

"Ist der eindeutige Schlüssel (UNIQUE) automatisch NULL-SAFE und schließt jede Anzahl von NULL-Werten in der Spalte aus?"

Tatsächlich erlauben die meisten DBMS (z. B. PostgreSQL, MySQL) die UNIQUE-Beschränkung, mehrere Zeilen mit dem Wert NULL, da NULL als "unbekannt" betrachtet wird. Dies führt oft zu unbemerkt gebliebenen Duplikationen von leeren Werten.

Beispiel:

CREATE TABLE test (
  id INT PRIMARY KEY,
  code VARCHAR(10) UNIQUE
);

INSERT INTO test (id, code) VALUES (1, NULL), (2, NULL); -- wird erfolgreich sein

Beispiele für realisierte Fehler aufgrund mangelnder Kenntnisse des Themas

---

Geschichte

Die Anwendung erlaubte die Registrierung per E-Mail, die Spalte war UNIQUE, aber NICHT NOT NULL — in der Tabelle gab es ein Dutzend Benutzer mit NULL-E-Mail, was bei der Integration mit externen Diensten Probleme verursachte.

---

Geschichte

Im Ticketbestellsystem wurde vergessen, einen FOREIGN KEY zur Tabelle payments hinzuzufügen — in der Folge gab es Zahlungen, die mit keiner Bestellung verbunden waren, was die Rückerstattung an die Nutzer erschwerte.

---

Geschichte

CHECK-Constraint für Rabatte: discount > 0. Die Grenzsituation für 0 wurde vergessen. Ergebnis: Das System akzeptierte nur Rabatte größer als 0, und das Fehlen eines Rabatts (0) brach die Geschäftslogik.