PostgreSQL håndhever dataintegritet gjennom begrensninger — regler på tabeldata. Utover standardene (, , , , , ), legger Postgres til kraftige alternativer som begrensninger og fleksible uttrykk.
PostgreSQL håndhever dataintegritet gjennom begrensninger — regler på tabeldata. Utover standardene (, , , , , ), legger Postgres til kraftige alternativer som begrensninger og fleksible uttrykk.
PRIMARY KEYFOREIGN KEYUNIQUENOT NULLCHECKDEFAULTCHECKCREATE TABLE bookings (
id SERIAL PRIMARY KEY, -- unique identifier
room_id INT NOT NULL REFERENCES rooms(id), -- foreign key (referential integrity)
email VARCHAR(255) UNIQUE NOT NULL, -- unique + required
guests INT CHECK (guests > 0 AND guests <= 10), -- value constraint
status TEXT DEFAULT 'pending' -- default value
);
PRIMARY KEY → unique row identifier
FOREIGN KEY → references another table (referential integrity, with ON DELETE options)
UNIQUE → no duplicate values
NOT NULL → must have a value
CHECK → value must satisfy a condition
DEFAULT → default value when not provided
CHECK (price > 0)
CHECK (end_date > start_date) -- logical consistency between columns
CHECK (status IN ('active', 'inactive', 'pending'))
CHECK (email ~ '^[^@]+@[^@]+\.[^@]+$') -- regex validation
Postgres CHECK begrensninger kan håndheve rike forretningsregler, inkludert betingelser på tvers av kolonner og regex-mønstre.
-- prevent OVERLAPPING bookings for the same room (impossible with UNIQUE alone!)
CREATE TABLE bookings (
room_id INT,
during TSRANGE, -- a time range
EXCLUDE USING GIST (room_id WITH =, during WITH &&) -- no two rows where room_id is
); -- equal AND time ranges OVERLAP
EXCLUDE begrensninger (en PostgreSQL-spesifikk funksjon) forhindrer rader som kommer i konflikt etter en egendefinert operator — berømt, forhindring av overlappende tidsperioder (dobbeltbookinger), noe som en UNIQUE begrensning ikke kan gjøre.
-- check constraints at COMMIT instead of immediately (useful for circular references)
FOREIGN KEY (...) REFERENCES ... DEFERRABLE INITIALLY DEFERRED
Begrensninger er essensielle for dataintegritet — de håndhever dataregler på databasenivå (siste forsvarslinje, alltid håndhevet uavhengig av applikasjonskode), så forståelse av PostgreSQLs begrensningsstøtte er viktig for å designe robuste databaser.
Å kjenne standard-begrensningene (PRIMARY KEY, FOREIGN KEY med referanseintegritet, UNIQUE, NOT NULL, CHECK, DEFAULT) og hva hver enkelt håndhever, er grunnleggende for skjemadesign, og gir garantier på databasenivå (unikhet, gyldige referanser, påkrevde verdier, gyldige data) som beskytter mot feil, kapløp og inkonsistent data på måter som applikasjonskode alene ikke kan.
PostgreSQLs CHECK begrensninger er særlig dyktige, og håndhever rike forretningsregler inkludert betingelser på tvers av kolonner (logisk konsistens som end_date > start_date) og til og med regex-mønstre — slik at du kan kode domeneregler direkte i skjemaet.
Særlig verdifull er den PostgreSQL-spesifikke EXCLUDE begrensningen, som forhindrer konflikterende rader ved egendefinerte operatorer — mest kjent forhindring av overlappende tidsperioder (dobbeltbookinger for et rom/ressurs), en kraftig kapabilitet som en standard UNIQUE begrensning ikke kan tilby og som elegant løser et vanlig problem fra den virkelige verden (planlegging, reservasjoner) på databasenivå.
Å forstå begrensningene — standard-begrensningene for integritet, Postgres sine fleksible CHECK-uttrykk, og den kraftige EXCLUDE for konfliktforhindring — er viktig for å designe databaser som håndhever korrekthet automatisk.
Siden dataintegritet er kritisk og begrensninger gir garantier som applikasjonskode ikke kan, og siden Postgres tilbyr kraftige alternativer (rike CHECK, EXCLUDE for overlapper) utover grunnlaget, er forståelse av PostgreSQLs begrensningsstøtte verdifull, praktisk relevant kunnskap for å bygge robuste databaser, der EXCLUDE-begrensningen spesielt er en distinktiv, nyttig PostgreSQL-kapabilitet som er verdt å kjenne for planleggings-/reservasjonssystemer.