Begrensninger er regler som håndheves av databasen på dataene i tabeller — og garanterer dataintegritet på databasenivå (ikke bare i applikasjonkode). De viktigste: PRIMARY KEY, FOREIGN KEY, UNIQUE, , , og .
Begrensninger er regler som håndheves av databasen på dataene i tabeller — og garanterer dataintegritet på databasenivå (ikke bare i applikasjonkode). De viktigste: 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
Databasebegrensninger er siste forsvarslinje for dataintegritet — de håndheves uansett hvilken kode som setter inn data (flere applikasjoner, skript, manuelle endringer, eller feilaktig kode), og de håndterer kapløpstilstander som applikasjonsnivå-sjekker mister.
CHECK (price > 0) -- prices must be positive
CHECK (status IN ('active', 'inactive')) -- only valid statuses
CHECK (end_date > start_date) -- logical consistency
CHECK håndhever forretnings-/domeneregler direkte i skjemaet.
Begrensninger er essensielle for å opprettholde dataintegritet — de garanterer at dataene i databasen din tilfredsstiller regler (unikhet, tilstedeværelse, gyldige verdier, gyldige referanser) på databasenivå, som er grunnleggende for pålitelige applikasjoner, så forståelse av dem er viktig.
Å kjenne begrensningtypene (PRIMARY KEY, FOREIGN KEY, UNIQUE, NOT NULL, CHECK, DEFAULT) og hva hver håndhever er nødvendig for riktig skjemadesign.
Det viktigste konseptuelle punktet er hvorfor håndheve på databasenivå i stedet for bare i applikasjonkode: databasebegrensninger er siste forsvarslinje for dataintegritet — de håndheves alltid uavhengig av hvilken kode eller hvor mange applikasjoner som får tilgang til dataene, de fanger feil som applikasjonssjekker kanskje mister, og avgjørende de håndterer kapløpstilstander som applikasjonsnivå-validering ikke kan (f.eks. to samtidige innsettinger som begge passerer en applikasjonsnivå-unikhet-sjekk men en UNIQUE-begrensning korrekt avviser duplikatet).
Å stole bare på applikasjonkode for integritet er risikabelt; begrensninger gir en garanti.
Å forstå CHECK-begrensninger for å håndheve domene-/forretningsregler (gyldige områder, tillatte verdier, logisk konsistens) direkte i skjemaet er også verdifullt.
Siden dataintegritet er kritisk for pålitelige applikasjoner, og siden begrensninger gir databasenivå-garantier som beskytter mot feil, kapløpstilstander, og inkonsistente data på måter som bare applikasjonkode ikke kan, er forståelse av begrensninger — typene, deres integritetsgarantier, og viktigheten av databasenivå-håndhevelse — viktig, grunnleggende kunnskap for å designe robuste databaser og et nøkkelaspekt ved å bygge applikasjoner hvis data forblir konsistente og gyldige.