Constraints sind Regeln, die von der Datenbank auf die Daten in Tabellen angewendet werden — sie garantieren Datenintegrität auf Datenbankebene (nicht nur im Anwendungscode). Die wichtigsten sind: PRIMARY KEY, FOREIGN KEY, UNIQUE, , und .
Constraints sind Regeln, die von der Datenbank auf die Daten in Tabellen angewendet werden — sie garantieren Datenintegrität auf Datenbankebene (nicht nur im Anwendungscode). Die wichtigsten sind: PRIMARY KEY, FOREIGN KEY, UNIQUE, , und .
NOT NULLCHECKDEFAULTCREATE TABLE users (
id INT PRIMARY KEY, -- unique + not null identifier
email VARCHAR(255) UNIQUE NOT NULL, -- must be unique AND present
age INT CHECK (age >= 0 AND age <= 120), -- must satisfy a condition
country VARCHAR(2) DEFAULT 'US', -- default value if not provided
role VARCHAR(20) NOT NULL DEFAULT 'user',
manager_id INT REFERENCES users(id) -- FOREIGN KEY (referential integrity)
);
PRIMARY KEY → uniquely identifies a row (unique + not null, indexed)
FOREIGN KEY → references another table's key (referential integrity)
UNIQUE → no duplicate values allowed in this column
NOT NULL → the column must have a value (can't be NULL)
CHECK → the value must satisfy a condition (age >= 0, status IN (...))
DEFAULT → a value used when none is provided on insert
-- ❌ relying only on application code to enforce uniqueness:
-- a race condition or a bug or a different app could insert a duplicate
-- ✅ a UNIQUE constraint guarantees it at the DB level — ALWAYS enforced,
-- regardless of which code or how many apps access the database
email VARCHAR(255) UNIQUE
Datenbankconstraints sind die letzte Verteidigungslinie für Datenintegrität — sie werden durchgesetzt, unabhängig davon, welcher Code Daten einfügt (mehrere Anwendungen, Scripts, manuelle Änderungen oder fehlerhafter Code), und sie handhaben Race Conditions, die Checks auf Anwendungsebene übersehen.
CHECK (price > 0) -- prices must be positive
CHECK (status IN ('active', 'inactive')) -- only valid statuses
CHECK (end_date > start_date) -- logical consistency
CHECK erzwingt Geschäfts-/Domänenregeln direkt im Schema.
Constraints sind essentiell für die Aufrechterhaltung der Datenintegrität — sie garantieren, dass die Daten in Ihrer Datenbank Regeln erfüllen (Eindeutigkeit, Präsenz, gültige Werte, gültige Referenzen) auf Datenbankebene, was fundamental für zuverlässige Anwendungen ist, daher ist das Verständnis dafür wichtig.
Die Constraint-Typen (PRIMARY KEY, FOREIGN KEY, UNIQUE, NOT NULL, CHECK, DEFAULT) und was jeder erzwingt, zu kennen, ist notwendig für korrektes Schema-Design.
Der wichtigste konzeptionelle Punkt ist warum Enforcement auf Datenbankebene anstatt nur im Anwendungscode: Datenbankconstraints sind die letzte Verteidigungslinie für Datenintegrität — sie werden immer durchgesetzt, unabhängig davon, welcher Code oder wie viele Anwendungen auf die Daten zugreifen, sie erkennen Fehler, die Anwendungschecks übersehen könnten, und entscheidend ist, dass sie Race Conditions handhaben, die Validierung auf Anwendungsebene nicht kann (z.B. zwei gleichzeitige Einfügungen, die beide einen Anwendungs-Eindeutigkeitscheck bestehen, aber ein UNIQUE Constraint das Duplikat korrekt ablehnt).
Sich nur auf Anwendungscode für Integrität zu verlassen ist riskant; Constraints bieten eine Garantie.
Das Verständnis von CHECK Constraints zum Erzwingen von Domänen-/Geschäftsregeln (gültige Bereiche, zulässige Werte, logische Konsistenz) direkt im Schema ist ebenfalls wertvoll.
Da Datenintegrität für zuverlässige Anwendungen kritisch ist, und da Constraints Garantien auf Datenbankebene bieten, die vor Fehlern, Race Conditions und inkonsistenten Daten in Wegen schützen, die reiner Anwendungscode nicht kann, ist das Verständnis von Constraints — den Typen, ihren Integritätsgarantien und der Wichtigkeit von Enforcement auf Datenbankebene — wichtiges, grundlegendes Wissen für die Gestaltung robuster Datenbanken und ein Schlüsselaspekt beim Aufbau von Anwendungen, deren Daten konsistent und gültig bleiben.
Eine Sammlung von IT-Interviewfragen mit ausführlichen Antworten — vom Junior bis zum Senior.
Spenden