Omejitve so pravila, ki jih baza podatkov uveljavlja na podatkih v tabelah — zagotavljajo celovitost podatkov na ravni baze podatkov (ne le v kodi aplikacije). Glavne so: PRIMARY KEY, FOREIGN KEY, UNIQUE, , in .
Omejitve so pravila, ki jih baza podatkov uveljavlja na podatkih v tabelah — zagotavljajo celovitost podatkov na ravni baze podatkov (ne le v kodi aplikacije). Glavne so: PRIMARY KEY, FOREIGN KEY, UNIQUE, , in .
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
Omejitve baze podatkov so zadnja linija obrambe za celovitost podatkov — uveljavijo se ne glede na to, katera koda vstavlja podatke (več aplikacij, skripti, ročne spremembe ali napačna koda), in ravnajo s pogoji dirke, ki jih aplikacijske preverjave spregledajo.
CHECK (price > 0) -- prices must be positive
CHECK (status IN ('active', 'inactive')) -- only valid statuses
CHECK (end_date > start_date) -- logical consistency
CHECK uveljavlja poslovne/domensko specifična pravila neposredno v shemi.
Omejitve so bistvene za vzdrževanje celovitosti podatkov — zagotavljajo, da podatki v bazi podatkov izpolnjujejo pravila (edinstvenost, prisotnost, veljavne vrednosti, veljavne reference) na ravni baze podatkov, kar je temeljno za zanesljive aplikacije, zato je razumevanje teh omejitev pomembno.
Poznavanje vrst omejitev (PRIMARY KEY, FOREIGN KEY, UNIQUE, NOT NULL, CHECK, DEFAULT) in kaj vsaka uveljavlja, je potrebno za pravilno zasnovo sheme.
Najpomembnejša konceptualna točka je zakaj uveljaviti na ravni baze podatkov in ne le v kodi aplikacije: omejitve baze podatkov so zadnja linija obrambe za celovitost podatkov — vedno se uveljavijo, ne glede na to, katera koda ali koliko aplikacij dostopa do podatkov, uhvatijo napake, ki jih aplikacijske preverjave morda spregledajo, in ključno je, da ravnajo s pogoji dirke, ki jih validacija na ravni aplikacije ne more (npr. dve sočasni vstavki, ki obe prestaneta aplikacijsko preverjavo edinstvenosti, vendar UNIQUE omejitev pravilno zavrne podvojeno vrednost).
Odvisnost le od kode aplikacije za celovitost je tvegana; omejitve zagotavljajo jamstvo.
Razumevanje CHECK omejitev za uveljavitev domenskih/poslovnih pravil (veljavna območja, dovoljene vrednosti, logična skladnost) neposredno v shemi je tudi dragoceno.
Ker je celovitost podatkov kritična za zanesljive aplikacije, in ker omejitve zagotavljajo jamstva na ravni baze podatkov, ki ščitijo pred napaka, pogoji dirke in nedosledni podatki na način, ki ga sama koda aplikacije ne more, je razumevanje omejitev — njihovih vrst, njihovih jamstev za celovitost in važnosti uveljavitve na ravni baze podatkov — pomembno temeljno znanje za načrtovanje robustnih baz podatkov in ključni vidik gradnje aplikacij, katerih podatki ostanejo skladni in veljavni.
Knjižnica IT vprašanj za razgovore s podrobnimi odgovori — od začetnika do izkušenega.
Doniraj