La dénormalisation ne vaut la peine que lorsque le modèle de lecture justifie la duplication_

Les équipes dénormalisent souvent pour la mauvaise raison : elles ont peur des jointures en général. Cela est généralement un signe d'une folklore de performance vague, et non de mesures concrètes.

La raison plus pertinente de dénormaliser est la forme de la charge de travail. Si un chemin de lecture est très actif, stable et coûteux à reconstruire encore et encore, alors la duplication d'un segment de données soigneusement choisi peut être le bon compromis.

Où la dénormalisation aide réellement

Un exemple courant est un tableau de bord des commandes qui a toujours besoin du même résumé joint :

• id de commande
• nom du client
• statut actuel
• montant total

Si cette page est extrêmement chaude, une option est de maintenir une table optimisée pour la lecture ou une vue matérialisée :

CREATE MATERIALIZED VIEW order_summaries AS
SELECT
  o.id,
  c.name AS customer_name,
  o.status,
  o.total_amount
FROM orders o
JOIN customers c ON c.id = o.customer_id;

C'est une technique de performance. Ce n'est pas une raison pour abandonner la conception relationnelle ailleurs.

Le compromis

La dénormalisation achète de la vitesse de lecture en introduisant une complexité d'écriture :

• données dupliquées
• logique de rafraîchissement
• règles d'invalidation
• risque de dérive lorsque la projection est obsolète

Si la requête n'est pas vraiment active, ou si l'indexation résout le problème, la dénormalisation peut simplement créer plus de travail de maintenance que de valeur.

Meilleure règle

Commencez par des tables normalisées et de bons index. Mesurez le véritable goulet d'étranglement. Dénormalisez uniquement lorsque le modèle de lecture est suffisamment stable pour que la duplication soit moins coûteuse que la recomposition.

Les jointures ne sont pas l'ennemi. Les décisions d'architecture non mesurées le sont.

Lectures complémentaires

• Astuces de performance PostgreSQL
• Vues matérialisées PostgreSQL