Dénormalisation assumée

Prérequis : cours précédent + 4.2 (CQRS/projections, Architecture).

Pourquoi

La normalisation protège l'écriture ; la lecture massive veut du plat. Dénormaliser, c'est acheter de la vitesse avec de la redondance — à condition de payer le prix consciemment (sync !).

Concepts

• Quoi dupliquer : ce qui se lit énormément et change peu (nom client dans les lignes, compteurs, libellés). Jamais : ce qui change souvent ou engage de l'argent sans garde.
• Comment synchroniser : événements/projections (propre), triggers (en base, atomique, à manier avec soin), batch nocturne (périmé assumé + heure connue).
• Compteurs : le cas n°1 (orders_count sur user). Options : trigger, job périodique, ou… ne pas stocker (compter à la volée si < 10k). Mesurer avant de dénormaliser !
• JSONB : le compromis Postgres — flexible dans du relationnel, requêtable ET indexable (GIN). 90 % du « NoSQL » sans quitter la base.

Exemple : compteur sans dérive

-- Trigger atomique (même transaction que l'écriture) :
CREATE FUNCTION bump_count() RETURNS trigger AS $$
BEGIN UPDATE users SET orders_count = orders_count + 1 WHERE id = NEW.customer_id; RETURN NEW; END $$ LANGUAGE plpgsql;
CREATE TRIGGER trg AFTER INSERT ON orders FOR EACH ROW EXECUTE FUNCTION bump_count();

Cas réel

total_spent maintenu « à la main » dans le code applicatif (oublié dans 2 chemins sur 5) : reporting faux de 12 %. Trigger atomique : juste depuis, par construction.

Pièges

• Dénormaliser sans sync définie : divergence silencieuse, découverte à l'audit (ou par un client).
• Dupliquer ce qui change souvent (prix !) : course permanente, bugs garantis.
• JSONB fourre-tout (« on mettra tout dedans ») : requêtes tordues + index GIN lourds. JSONB pour le flexible, colonnes pour le structuré.

À retenir

Lire énorme + change peu = dupliquer ; sync définie (trigger/event) ; JSONB = flexible indexé.