Ograniczenia to reguły wymuszane przez bazę danych na danych w tabelach — gwarantujące integralność danych na poziomie bazy danych (nie tylko w kodzie aplikacji). Główne z nich to: PRIMARY KEY, FOREIGN KEY, UNIQUE, , i .
Ograniczenia to reguły wymuszane przez bazę danych na danych w tabelach — gwarantujące integralność danych na poziomie bazy danych (nie tylko w kodzie aplikacji). Główne z nich to: PRIMARY KEY, FOREIGN KEY, UNIQUE, , i .
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
Ograniczenia bazy danych są ostatnią linią obrony dla integralności danych — są egzekwowane niezależnie od tego, jaki kod wstawia dane (wiele aplikacji, skrypty, zmiany manualne lub błędny kod), i obsługują warunki wyścigu, które sprawdzenia na poziomie aplikacji mogą pominąć.
CHECK (price > 0) -- prices must be positive
CHECK (status IN ('active', 'inactive')) -- only valid statuses
CHECK (end_date > start_date) -- logical consistency
CHECK wymusza reguły biznesowe/domenowe bezpośrednio w schemacie.
Ograniczenia są niezbędne do utrzymania integralności danych — gwarantują, że dane w bazie spełniają reguły (unikatowość, obecność, prawidłowe wartości, prawidłowe odniesienia) na poziomie bazy danych, co jest fundamentem dla niezawodnych aplikacji, dlatego zrozumienie ich jest ważne.
Znajomość typów ograniczeń (PRIMARY KEY, FOREIGN KEY, UNIQUE, NOT NULL, CHECK, DEFAULT) i tego, co każde z nich wymusza, jest konieczna do prawidłowego projektowania schematu.
Najważniejszym punktem koncepcyjnym jest dlaczego egzekwować na poziomie bazy danych zamiast tylko w kodzie aplikacji: ograniczenia bazy danych są ostatnią linią obrony dla integralności danych — są zawsze egzekwowane niezależnie od tego, który kod lub ile aplikacji uzyskuje dostęp do danych, łapią błędy, które sprawdzenia aplikacji mogą przegapić, i co najważniejsze obsługują warunki wyścigu (race conditions), których walidacja na poziomie aplikacji nie może (np. dwa jednoczesne wstawienia, zarówno przechodzące sprawdzenie unikatowości na poziomie aplikacji, ale ograniczenie UNIQUE prawidłowo odrzucające duplikat).
Poleganie wyłącznie na kodzie aplikacji dla integralności jest ryzykowne; ograniczenia zapewniają gwarancję.
Zrozumienie ograniczeń CHECK do egzekwowania reguł domenowych/biznesowych (zakresy prawidłowe, dozwolone wartości, spójność logiczna) bezpośrednio w schemacie jest również cenne.
Ponieważ integralność danych jest krytyczna dla niezawodnych aplikacji, a ograniczenia zapewniają gwarancje na poziomie bazy danych, które chronią przed błędami, warunkami wyścigu i niespójnymi danymi w sposób, którego sam kod aplikacji nie może, zrozumienie ograniczeń — ich typów, gwarancji integralności i znaczenia egzekwowania na poziomie bazy danych — jest ważną, fundamentalną wiedzą do projektowania solidnych baz danych i kluczowym aspektem budowania aplikacji, których dane pozostają spójne i prawidłowe.