Rajoitukset ovat tietokannan valvomia sääntöjä taulujen tiedoille — takaaen tietojen eheyden tietokantatasolla (ei vain sovelluskoodissa). Pääasialliset: PRIMARY KEY, FOREIGN KEY, UNIQUE, NOT NULL, ja .
Rajoitukset ovat tietokannan valvomia sääntöjä taulujen tiedoille — takaaen tietojen eheyden tietokantatasolla (ei vain sovelluskoodissa). Pääasialliset: PRIMARY KEY, FOREIGN KEY, UNIQUE, NOT NULL, ja .
CHECKDEFAULTCREATE 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
Tietokannan rajoitukset ovat viimeinen puolustusviiva tietojen eheydelle — ne valvotaan riippumatta siitä, mitä koodia lisää tietoja (useita sovelluksia, skriptejä, manuaalisia muutoksia tai virheellistä koodia), ja ne käsittelevät kilpailuolosuhteita, joita sovellustason tarkistukset jäävät huomaamatta.
CHECK (price > 0) -- prices must be positive
CHECK (status IN ('active', 'inactive')) -- only valid statuses
CHECK (end_date > start_date) -- logical consistency
CHECK pakottaa liiketoiminnalliset/domeenisäännöt suoraan skeemaan.
Rajoitukset ovat välttämättömiä tietojen eheyden ylläpitämiselle — ne takaavat, että tietokannassa olevat tiedot täyttävät säännöt (ainutlaatuisuus, läsnäolo, kelvolliset arvot, kelvolliset viittaukset) tietokantatasolla, mikä on olennaista luotettaville sovelluksille, joten niiden ymmärtäminen on tärkeää.
Rajoitustyyppien (PRIMARY KEY, FOREIGN KEY, UNIQUE, NOT NULL, CHECK, DEFAULT) tunteminen ja kunkin valvoman asian ymmärtäminen on välttämätöntä oikealle skeemasuunnittelulle.
Tärkein käsitteellinen näkökohta on miksi valvoa tietokantatasolla sovelluskoodissa vain valvomisen sijasta: tietokannan rajoitukset ovat viimeinen puolustusviiva tietojen eheydelle — ne valvotaan aina riippumatta siitä, mitä koodia käyttää tietoja tai kuinka monta sovellusta käyttää tietoja, ne kiinni virheistä, joita sovellustason tarkistukset saattavat jäädä huomaamatta, ja ratkaisevasti ne käsittelevät kilpailuolosuhteita, joita sovellustason validointi ei voi (esim. kaksi samanaikaista lisäystä molemmat läpäisee sovellustason ainutlaatuisuustarkistuksen mutta UNIQUE-rajoitus oikein hylkää kopion).
Pelkän sovelluskoodin varaaminen eheydelle on riskialtista; rajoitukset tarjoavat takuun.
CHECK-rajoitusten ymmärtäminen domeenitälle/liiketoimintasäännöille (kelvolliset alueet, sallitut arvot, looginen yhdenmukaisuus) suoraan skeemassa on myös arvokas.
Koska tietojen eheys on kriittistä luotettaville sovelluksille, ja koska rajoitukset tarjoavat tietokantatasoiset takuut, jotka suojaavat virheiltä, kilpailuolosuhteelta ja epäjohdonmukaisilta tiedoilta tavoin, jota pelkkä sovellukskoodi ei voi, rajoitusten ymmärtäminen — tyypit, niiden eheyden takuut ja tietokantatasoisella valvomisen tärkeys — on tärkeää, perustavanlaatuista tietoa vankkoja tietokantoja suunnitteleville ja keskeinen osa sovellusten rakentamista, joiden tiedot pysyvät yhdenmukaisina ja kelpoina.
Kirjasto IT-haastattelukysymyksiä yksityiskohtaisine vastauksineen — Juniorista Senioriin.
Lahjoita