Les contraintes sont des règles appliquées par la base de données sur les données des tables — garantissant l'intégrité des données au niveau de la base de données (pas seulement dans le code applicatif). Les principales sont : PRIMARY KEY, FOREIGN KEY, , , et .
UNIQUENOT 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
Les contraintes de base de données sont la dernière ligne de défense pour l'intégrité des données — elles sont appliquées indépendamment du code qui insère les données (plusieurs applications, scripts, modifications manuelles ou code bugué), et elles gèrent les conditions de concurrence que les contrôles au niveau applicatif manquent.
CHECK (price > 0) -- prices must be positive
CHECK (status IN ('active', 'inactive')) -- only valid statuses
CHECK (end_date > start_date) -- logical consistency
CHECK applique les règles métier/domaine directement dans le schéma.
Les contraintes sont essentielles pour maintenir l'intégrité des données — elles garantissent que les données de votre base de données satisfont des règles (unicité, présence, valeurs valides, références valides) au niveau de la base de données, ce qui est fondamental pour des applications fiables, c'est pourquoi les comprendre est important.
Connaître les types de contraintes (PRIMARY KEY, FOREIGN KEY, UNIQUE, NOT NULL, CHECK, DEFAULT) et ce que chacune applique est nécessaire pour une conception correcte du schéma.
Le point conceptuel le plus important est pourquoi appliquer au niveau de la base de données plutôt que seulement dans le code applicatif : les contraintes de base de données sont la dernière ligne de défense pour l'intégrité des données — elles sont toujours appliquées indépendamment du code qui y accède ou du nombre d'applications, elles détectent les bugs que les contrôles applicatifs pourraient manquer, et surtout elles gèrent les conditions de concurrence que la validation au niveau applicatif ne peut pas gérer (par exemple, deux insertions simultanées passant toutes les deux un contrôle d'unicité au niveau applicatif mais une contrainte UNIQUE rejetant correctement le doublon).
S'appuyer uniquement sur le code applicatif pour l'intégrité est risqué ; les contraintes fournissent une garantie.
Comprendre les contraintes CHECK pour appliquer des règles métier/domaine (plages valides, valeurs autorisées, cohérence logique) directement dans le schéma est également précieux.
Comme l'intégrité des données est cruciale pour des applications fiables, et comme les contraintes fournissent des garanties au niveau de la base de données qui protègent contre les bugs, les conditions de concurrence et les données incohérentes d'une manière que le code applicatif seul ne peut pas, comprendre les contraintes — les types, leurs garanties d'intégrité et l'importance de l'application au niveau de la base de données — est une connaissance importante et fondamentale pour concevoir des bases de données robustes et un aspect clé de la construction d'applications dont les données restent cohérentes et valides.