Ограничения — это правила, которые база данных применяет к данным в таблицах, гарантируя целостность данных на уровне базы данных (а не только в коде приложения). Основные: PRIMARY KEY, FOREIGN KEY, UNIQUE, , и .
Ограничения — это правила, которые база данных применяет к данным в таблицах, гарантируя целостность данных на уровне базы данных (а не только в коде приложения). Основные: PRIMARY KEY, FOREIGN KEY, UNIQUE, , и .
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
Ограничения базы данных — это последняя линия защиты для целостности данных — они применяются независимо от того, какой код вставляет данные (несколько приложений, скрипты, ручные изменения или ошибочный код), и они обрабатывают состояния гонки, которые пропускают проверки на уровне приложения.
CHECK (price > 0) -- prices must be positive
CHECK (status IN ('active', 'inactive')) -- only valid statuses
CHECK (end_date > start_date) -- logical consistency
CHECK применяет бизнес-правила/правила предметной области прямо в схему.
Ограничения необходимы для поддержания целостности данных — они гарантируют, что данные в базе данных удовлетворяют правилам (уникальность, наличие, допустимые значения, допустимые ссылки) на уровне базы данных, что является основополагающим для надежных приложений, поэтому их понимание важно.
Знание типов ограничений (PRIMARY KEY, FOREIGN KEY, UNIQUE, NOT NULL, CHECK, DEFAULT) и того, что каждое из них применяет, необходимо для правильного проектирования схемы.
Наиболее важная концептуальная идея — почему применять ограничения на уровне базы данных, а не только в коде приложения: ограничения базы данных — это последняя линия защиты для целостности данных — они всегда применяются независимо от того, какой код или сколько приложений обращаются к данным, они ловят ошибки, которые проверки приложения могут пропустить, и решающий момент — они обрабатывают состояния гонки, которые валидация на уровне приложения не может (например, две одновременные вставки, обе прошедшие проверку уникальности на уровне приложения, но ограничение UNIQUE правильно отклоняющее дубликат).
Полагаться только на код приложения для целостности рискованно; ограничения обеспечивают гарантию.
Понимание ограничений CHECK для применения правил предметной области/бизнеса (допустимые диапазоны, разрешенные значения, логическая согласованность) прямо в схеме также ценно.
Поскольку целостность данных критична для надежных приложений, и поскольку ограничения обеспечивают гарантии на уровне базы данных, которые защищают от ошибок, состояний гонки и несогласованных данных так, как один только код приложения не может, понимание ограничений — типов, их гарантий целостности и важности применения на уровне базы данных — это важное, фундаментальное знание для проектирования надежных баз данных и ключевой аспект создания приложений, чьи данные остаются согласованными и валидными.