Begrænsninger er regler, som databasen håndhæver på data i tabeller — og garanterer dataintegritet på databaseniveauet (ikke blot i applikationskode). De vigtigste er: PRIMARY KEY, FOREIGN KEY, UNIQUE, , og .
Begrænsninger er regler, som databasen håndhæver på data i tabeller — og garanterer dataintegritet på databaseniveauet (ikke blot i applikationskode). De vigtigste er: PRIMARY KEY, FOREIGN KEY, UNIQUE, , og .
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
Databasebegrænsninger er sidste skanse for dataintegritet — de håndhæves uanset hvilken kode, der indsætter data (flere applikationer, scripts, manuelle ændringer eller fejlbehæftet kode), og de håndterer race conditions, som applikationsniveaubegrænsninger mister af syne.
CHECK (price > 0) -- prices must be positive
CHECK (status IN ('active', 'inactive')) -- only valid statuses
CHECK (end_date > start_date) -- logical consistency
CHECK håndhæver forretnings-/domæneregler direkte i skemaet.
Begrænsninger er essentielle for at opretholde dataintegritet — de garanterer, at data i databasen opfylder regler (unikhed, tilstedeværelse, gyldige værdier, gyldige referencer) på databaseniveauet, hvilket er grundlæggende for pålidelige applikationer, så forståelse heraf er vigtig.
At kende begrænsningtyperne (PRIMARY KEY, FOREIGN KEY, UNIQUE, NOT NULL, CHECK, DEFAULT) og hvad hver især håndhæver, er nødvendigt for korrekt skemadesign.
Den vigtigste konceptuelle pointe er hvorfor man skal håndhæve på databaseniveauet i stedet for kun i applikationskode: databasebegrænsninger er sidste skanse for dataintegritet — de håndhæves altid uanset hvilken kode eller hvor mange applikationer, der får adgang til data, de fanger fejl, som applikationsbegrænsninger måske overser, og vigtigst af alt håndterer de race conditions, som applikationsniveauvalidering ikke kan (f.eks. to samtidige indsættelser, som begge passerer en appniveaubegrænsning for unikhed, men en UNIQUE-begrænsning korrekt afviser duplikatet).
At være afhængig udelukkende af applikationskode for integritet er risikofyldt; begrænsninger giver en garanti.
At forstå CHECK-begrænsninger for at håndhæve domæne-/forretningsregler (gyldige områder, tilladte værdier, logisk konsistens) direkte i skemaet er også værdifuldt.
Da dataintegritet er kritisk for pålidelige applikationer, og da begrænsninger giver databaseniveaugarantier, som beskytter mod fejl, race conditions og inkonsistent data på måder, som applikationskode alene ikke kan, er forståelse af begrænsninger — typerne, deres integritetsgarantier og vigtigheden af databaseniveauhåndhævelse — vigtig, grundlæggende viden for at designe robuste databaser og en vigtig aspekt af at bygge applikationer, hvis data forbliver konsistent og gyldige.