Begränsningar är regler som tillämpas av databasen på data i tabeller — och garanterar dataintegritet på databasnivå (inte bara i programkod). De viktigaste är: PRIMARY KEY, FOREIGN KEY, UNIQUE, , och .
Begränsningar är regler som tillämpas av databasen på data i tabeller — och garanterar dataintegritet på databasnivå (inte bara i programkod). De viktigaste är: PRIMARY KEY, FOREIGN KEY, UNIQUE, , och .
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
Databasbegränsningar är sista försvarslinje för dataintegritet — de tillämpas oavsett vilken kod som infogar data (flera program, skript, manuella ändringar eller felaktig kod), och de hanterar race conditions som programnivåkontroller missar.
CHECK (price > 0) -- prices must be positive
CHECK (status IN ('active', 'inactive')) -- only valid statuses
CHECK (end_date > start_date) -- logical consistency
CHECK tillämpar affärs-/domänregler direkt i schemat.
Begränsningar är väsentliga för att upprätthålla dataintegritet — de garanterar att data i databasen uppfyller regler (unikhet, närvaro, giltiga värden, giltiga referenser) på databasnivå, vilket är grundläggande för tillförlitliga program, så att förstå dem är viktigt.
Att känna till begränsningstyper (PRIMARY KEY, FOREIGN KEY, UNIQUE, NOT NULL, CHECK, DEFAULT) och vad var och en tillämpar är nödvändigt för korrekt schemadesign.
Den viktigaste konceptuella poängen är varför man tillämpar på databasnivå istället för bara i programkod: databasbegränsningar är sista försvarslinje för dataintegritet — de tillämpas alltid oavsett vilken kod eller hur många program som får åtkomst till data, de fångar buggar som programkontroller kan missa, och helt avgörande är att de hanterar race conditions som validering på programnivå inte kan (t.ex. två samtidiga infogningar som båda passerar en app-nivåkontroll för unikhet men en UNIQUE-begränsning korrekt förkastas dupliceringen).
Att förlita sig enbart på programkod för integritet är riskabelt; begränsningar ger en garanti.
Att förstå CHECK-begränsningar för att tillämpa domän-/affärsregler (giltiga intervall, tillåtna värden, logisk konsekvens) direkt i schemat är också värdefullt.
Eftersom dataintegritet är kritisk för tillförlitliga program, och eftersom begränsningar ger garantier på databasnivå som skyddar mot buggar, race conditions och inkonsistent data på sätt som enbart programkod inte kan, är förståelse för begränsningar — typerna, deras integritetsgarantier och vikten av tillämpning på databasnivå — viktigt, grundläggande kunskap för att designa robusta databaser och en nyckelaspekt av att bygga program vars data förblir konsistent och giltig.