Normalisation : modéliser juste

Prérequis (cursus dev) : tables et relations, entités et relations.

Pourquoi

Une base mal modélisée pourrit tout : doublons qui divergent, suppressions qui cassent, requêtes tordues. Les formes normales sont un checklist, pas un dogme — les connaître, c'est modéliser vite ET juste.

Concepts

• 1NF : valeurs atomiques (pas de tags en CSV dans une colonne !), lignes identifiables (clé primaire partout, sans exception).
• 2NF/3NF : chaque attribut dépend de la clé, de toute la clé, et de rien d'autre (pas de transitif : la ville du client ne vit pas dans la commande, mais via le client).
• Clés : primaires (UUID publics non devinables vs serial internes — cf. Extensions), étrangères + ON DELETE explicite (RESTRICT par défaut réfléchi, CASCADE assumé, SET NULL documenté).
• Contraintes : NOT NULL, UNIQUE, CHECK (prix >= 0), EXCLUDE : la base refuse l'incohérent — le dernier rempart (cf. DevOps 4.1/ACID).

Exemple : la commande propre

CREATE TABLE orders (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  customer_id UUID NOT NULL REFERENCES customers(id),
  total_cents INT NOT NULL CHECK (total_cents >= 0),
  status TEXT NOT NULL DEFAULT 'pending',
  created_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

Cas réel

Emails clients dupliqués dans 3 tables « pour aller vite » : changement d'email = 2 tables sur 3 mises à jour, envois à l'ancienne adresse pendant des mois. Une table customers, des références : fini.

Pièges

• ON DELETE CASCADE par défaut partout : une suppression user efface factures + logs (légal ?). Choisir par relation.
• CSV dans une colonne (« tags ») : requêtes impossibles, index inutiles → table de liaison ou JSONB.
• Pas de clé primaire « parce que table de liaison » : toute table a une PK (même composite), sinon doublons et updates aveugles.

À retenir

Atomique + PK partout, dépendances propres (3NF), DELETE explicite, contraintes = dernier rempart.