Un exemple concret d'impact : une table de 10 millions de lignes utilisant VARCHAR(255) pour stocker des IDs numériques consomme en moyenne 4 fois plus d'espace qu'avec INT, et les jointures prennent 2 à 3 fois plus de temps (benchmark PostgreSQL 16, pgbench).

Modéliser les relations : 1-1, 1-N et N-M

Relation un-à-plusieurs (1-N)

C'est la relation la plus courante. Un client a plusieurs commandes. La clé étrangère se place du côté "plusieurs".

CREATE TABLE clients (
  id    INT PRIMARY KEY,
  email VARCHAR(255) UNIQUE NOT NULL
);

CREATE TABLE commandes (
  id         INT PRIMARY KEY,
  client_id  INT NOT NULL REFERENCES clients(id) ON DELETE CASCADE,
  montant    DECIMAL(10,2) NOT NULL,
  created_at TIMESTAMPTZ DEFAULT NOW()
);

ON DELETE CASCADE supprime automatiquement les commandes quand un client est supprimé. Utilisez-le avec précaution : dans certains contextes métier, on préfère ON DELETE RESTRICT pour protéger l'historique.

Relation plusieurs-à-plusieurs (N-M)

Une relation N-M nécessite une table de jonction. Par exemple, un produit peut appartenir à plusieurs catégories, et une catégorie contient plusieurs produits.

CREATE TABLE produits (
  id  INT PRIMARY KEY,
  nom VARCHAR(200) NOT NULL
);

CREATE TABLE categories (
  id  INT PRIMARY KEY,
  nom VARCHAR(100) NOT NULL
);

CREATE TABLE produits_categories (
  produit_id  INT REFERENCES produits(id),
  categorie_id INT REFERENCES categories(id),
  PRIMARY KEY (produit_id, categorie_id)
);

La clé primaire composite sur (produit_id, categorie_id) garantit qu'un même produit ne peut pas être associé deux fois à la même catégorie.

Relation un-à-un (1-1)

Moins fréquente, elle sert souvent à séparer des données rarement accédées (profil étendu, préférences) de la table principale pour alléger les lectures courantes.

CREATE TABLE utilisateurs (
  id    INT PRIMARY KEY,
  email VARCHAR(255) UNIQUE NOT NULL
);

CREATE TABLE profils_etendus (
  utilisateur_id INT PRIMARY KEY REFERENCES utilisateurs(id),
  biographie     TEXT,
  site_web       VARCHAR(500)
);

Contraintes d'intégrité : votre filet de sécurité

Les contraintes ne sont pas optionnelles : elles sont votre première ligne de défense contre les données corrompues. Pour approfondir ce sujet, consultez notre article sur les contraintes SQL PRIMARY KEY et FOREIGN KEY.

Voici les contraintes essentielles à connaître :

CREATE TABLE produits (
  id          INT          PRIMARY KEY,
  reference   VARCHAR(50)  UNIQUE NOT NULL,
  nom         VARCHAR(200) NOT NULL,
  prix        DECIMAL(10,2) NOT NULL CHECK (prix >= 0),
  stock       INT          NOT NULL DEFAULT 0 CHECK (stock >= 0),
  categorie   VARCHAR(50)  NOT NULL CHECK (categorie IN ('électronique', 'vêtement', 'alimentaire')),
  created_at  TIMESTAMPTZ  NOT NULL DEFAULT NOW()
);

Chaque contrainte ici joue un rôle précis :

• PRIMARY KEY : unicité et accès rapide par ID
• UNIQUE : interdit les références dupliquées
• NOT NULL : garantit l'absence de valeurs manquantes sur les champs critiques
• CHECK : valide la logique métier directement en base
• DEFAULT : valeur par défaut pour éviter les oublis applicatifs

Indexation : concevoir pour vos requêtes réelles

Un schéma sans stratégie d'indexation est incomplet. Les index accélèrent les lectures mais ralentissent les écritures : il faut donc indexer judicieusement.

Pour aller plus loin sur ce sujet, notre guide sur les index SQL et leur optimisation pour la performance couvre tous les types d'index en détail.

Voici les règles de base à appliquer lors de la conception :

Indexez systématiquement :

• Les colonnes utilisées dans les clauses WHERE fréquentes
• Les colonnes de jointure (clés étrangères)
• Les colonnes dans ORDER BY et GROUP BY sur de grandes tables

N'indexez pas :

• Les colonnes avec très peu de valeurs distinctes (ex. booléen sur une petite table)
• Les tables de moins de 10 000 lignes (le coût dépasse le bénéfice)
• Les colonnes rarement utilisées en filtrage

-- Index simple sur clé étrangère
CREATE INDEX idx_commandes_client ON commandes(client_id);

-- Index composite pour une requête fréquente
CREATE INDEX idx_commandes_client_date
  ON commandes(client_id, created_at DESC);

-- Index partiel : uniquement les commandes non traitées
CREATE INDEX idx_commandes_en_attente
  ON commandes(created_at)
  WHERE statut = 'en_attente';

L'index partiel est particulièrement puissant : si 90 % de vos lectures portent sur les commandes en attente (qui représentent 5 % de la table), l'index partiel est 18 fois plus petit et plus rapide qu'un index complet.

Dénormalisation : quand casser les règles est rentable

La normalisation est le point de départ, pas une règle absolue. Dans certains contextes, une dénormalisation contrôlée améliore significativement les performances.

Technique	Quand l'utiliser	Avantage	Inconvénient
Colonne calculée stockée	Calcul coûteux exécuté très souvent	Lecture instantanée	Mise à jour à gérer
Duplication de colonne	Jointure évitable sur hot path	Requête sans JOIN	Risque d'incohérence
Table agrégée (résumé)	Dashboard avec millions de lignes	Réponse en ms vs secondes	Fraîcheur des données
Colonne JSON/JSONB	Attributs variables par entité	Schéma flexible	Indexation partielle seulement