Beperkingen zijn regels die door de database op de gegevens in tabellen worden afgedwongen — waardoor gegevensintegriteit op databaseniveau wordt gegarandeerd (niet alleen in applicatiecode). De voornaamste zijn: PRIMARY KEY, FOREIGN KEY, UNIQUE, , , en .
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
Databasebeperkingen zijn de laatste verdedigingslinie voor gegevensintegriteit — ze worden afgedwongen ongeacht welke code gegevens invoegt (meerdere applicaties, scripts, handmatige wijzigingen of buggy code), en ze hanteren raceomstandigheden die controles op applicatieniveau missen.
CHECK (price > 0) -- prices must be positive
CHECK (status IN ('active', 'inactive')) -- only valid statuses
CHECK (end_date > start_date) -- logical consistency
CHECK dwingt bedrijfs-/domeinregels rechtstreeks in het schema af.
Beperkingen zijn essentieel voor het handhaven van gegevensintegriteit — ze garanderen dat de gegevens in uw database regels (uniciteit, aanwezigheid, geldige waarden, geldige verwijzingen) op databaseniveau satisfiëren, wat fundamenteel is voor betrouwbare applicaties, dus het begrijpen ervan is belangrijk.
Het kennen van de beperkingstypes (PRIMARY KEY, FOREIGN KEY, UNIQUE, NOT NULL, CHECK, DEFAULT) en wat elk afdwingt is noodzakelijk voor correct schemaontwerp.
Het belangrijkste conceptuele punt is waarom handhaving op databaseniveau in plaats van alleen in applicatiecode: databasebeperkingen zijn de laatste verdedigingslinie voor gegevensintegriteit — ze worden altijd afgedwongen ongeacht welke code of hoeveel applicaties de gegevens benaderen, ze vangen bugs op die applicatiecontroles mogelijk missen, en crucciaal zij hanteren raceomstandigheden die validatie op applicatieniveau niet kan (bijv. twee gelijktijdige invoegingen die beide een appcontrole op uniciteit passeren maar een UNIQUE-beperking correct de duplicaat afwijst).
Vertrouwen uitsluitend op applicatiecode voor integriteit is risicovol; beperkingen bieden een garantie.
Het begrijpen van CHECK-beperkingen voor het afdwingen van domein-/bedrijfsregels (geldige bereiken, toegestane waarden, logische consistentie) rechtstreeks in het schema is ook waardevol.
Angezien gegevensintegriteit kritiek is voor betrouwbare applicaties, en aangezien beperkingen databaseniveau-garanties bieden die beschermen tegen bugs, raceomstandigheden en inconsistente gegevens op manieren die applicatiecode alleen niet kan, is het begrijpen van beperkingen — de types, hun integriteitsgaranties, en het belang van handhaving op databaseniveau — belangrijk, fundamenteel kennisveld voor het ontwerpen van robuuste databases en een belangrijk aspect van het bouwen van applicaties waarvan de gegevens consistent en geldig blijven.