Quand enfreindre les règles de base de données :3 cas

Savoir quand enfreindre les règles de base de données, c'est avoir une raison précise et documentée — et en pratique, seules trois raisons résistent à l'examen. Les données vraiment flexibles peuvent vivre en JSONB plutôt que dans des tables rigides. Les compteurs trop coûteux à calculer en direct peuvent être stockés. Et l'argent est toujours stocké en centimes entiers. Tout le reste reste strictement structuré.

J'ai consacré beaucoup de mots à prêcher la structure : chaque fait à un seul endroit, tout relié par des références, aucun raccourci. Cette règle — la discipline des 90 % et plus abordée dans l'article sur la normalisation des bases de données — a permis de construire une plateforme où des centaines de tables restent synchronisées sans aucune donnée dupliquée. Cet article parle de l'autre côté : les 10 %, où enfreindre les règles n'est pas un raccourci mais la bonne décision d'ingénierie.

Quand enfreindre les règles de base de données : la règle avant les exceptions

D'abord, le cadre. Sur ma plateforme, environ 95 % des données sont relationnelles — de vraies tables, de vraies références, une vraie structure. Les exceptions sont exactement cela : des exceptions, chacune avec une raison écrite. Cet ordre compte, car l'IA vous proposera constamment d'enfreindre les règles, et « c'est plus simple » n'est jamais la raison. Le danger n'est pas l'exception ; c'est l'exception non documentée que personne ne peut plus tard distinguer d'une erreur.

Cela dit, voici les trois entorses que j'utilise à dessein.

Exception 1 : le JSONB pour les données vraiment flexibles

PostgreSQL — le moteur de base de données derrière la plupart des produits SaaS modernes — a un super-pouvoir appelé JSONB. Il permet à une seule colonne de contenir un document entier de forme libre : n'importe quels champs, n'importe quelle forme, différente pour chaque ligne. C'est la porte de sortie du monde structuré.

Voyez votre base de données comme un classeur à tiroirs étiquetés. Le JSONB est le tiroir « divers » — et un tiroir « divers » est réellement utile, tant qu'il ne devient jamais l'endroit où vous rangez votre passeport. Le contenu légitime : des choses dont vous ne pouvez pas connaître la forme à l'avance. Si vos utilisateurs créent des formulaires personnalisés, chaque soumission a des champs différents — vous ne pouvez pas prévoir un tiroir pour des champs qui n'existent pas encore. Il en va de même pour les champs personnalisés définis par l'utilisateur, les préférences et réglages par utilisateur, les charges utiles qui arrivent des systèmes d'autres entreprises, les métadonnées libres, et les instantanés avant/après dans les journaux d'audit.

La règle en une phrase que je suis :

Si vous avez besoin de le relier à d'autres données, de l'interroger souvent ou d'imposer des relations — rendez-le relationnel. S'il est flexible, défini par l'utilisateur ou rarement interrogé — le JSONB convient.

Le signe que le JSONB est sûr : la donnée appartient à une seule ligne et n'est jamais interrogée indépendamment d'elle. C'est exactement la situation où les problèmes de mise à jour que la structure existe pour prévenir ne peuvent pas survenir. Le signe que c'est une erreur : vous vous surprenez à vouloir poser des questions à travers le JSONB — « toutes les tâches marquées urgentes », « toutes les commandes de ce client ». Ce sont des relations, et les relations appartiennent aux tables.

12 semainesVotre carrière en entreprise n'a jamais été le planPostulez au Solopreneur Accelerator.Postuler →

Exception 2 : les compteurs que vous ne pouvez pas vous permettre de calculer en direct

La structure stricte dit : ne stockez jamais ce que vous pouvez calculer. Le nombre de membres d'un canal, la note moyenne d'une annonce, le nombre de candidatures à une offre d'emploi — tout cela peut être calculé à la demande en comptant les enregistrements sous-jacents, et à petite échelle, c'est exactement ce qu'il faut faire.

Puis l'échelle arrive. Une communauté où les canaux contiennent 100 000 publications ne peut pas les recompter à chaque affichage de page. Une place de marché de 500 000 annonces ne peut pas recalculer les notes moyennes dans chaque résultat de recherche. Un site d'emploi où les entreprises reçoivent 50 000 candidatures ne peut pas les compter en direct à chaque consultation de profil. À ce stade, vous stockez le nombre — une colonne de compteur précalculé — et le lire ne coûte rien.

Voici la discipline qui évite que cela pourrisse : chaque compteur stocké a besoin d'un mécanisme de maintenance — un déclencheur (trigger) ou une fonction de base de données qui le met à jour à l'instant où les données sous-jacentes changent. Un compteur sans mécanisme n'est pas une optimisation ; c'est un mensonge qui attend qu'on le croie. Dans mon schéma, chaque colonne de compteur a un mécanisme documenté qui la maintient synchronisée, et les notes de conception consignent lequel et quand il se déclenche.

Un raffinement à reprendre : les compteurs de vues sont l'exception dans l'exception. Ils sont mis à jour de façon asynchrone — déclenchés depuis la page après son chargement — plutôt que par un trigger, de sorte que compter les vues ne ralentit jamais une page, que les bots peuvent être filtrés et que les vues répétées peuvent être dédupliquées. Les compteurs exacts (membres, votes, candidatures) reçoivent des triggers ; les compteurs de vanité reçoivent le traitement assoupli.

Exception 3 : l'argent est toujours en centimes entiers

Celle-ci relève moins d'« enfreindre une règle » que du refus d'un réglage par défaut qui paraît naturel et qui est silencieusement dangereux. Stocker 12,99 € sous la forme du nombre décimal 12.99 invite l'arithmétique à virgule flottante de l'ordinateur dans vos finances — et le calcul à virgule flottante produit de minuscules erreurs d'arrondi, simplement laides sur un graphique et inacceptables sur une facture.

Le correctif : stockez chaque montant monétaire sous la forme d'un nombre entier de centimes. 12,99 € est stocké comme 1299. Les nombres entiers n'ont jamais d'erreurs d'arrondi. Tout le système de paiement de Stripe parle cette convention — des montants dans la plus petite unité monétaire — donc votre base de données s'aligne nativement sur votre prestataire de paiement. La division par 100 n'intervient qu'au dernier moment, dans la couche d'affichage, où une erreur coûte un bug cosmétique plutôt que de l'argent.

Dans mon schéma, c'est absolu : chaque prix, frais, pourboire et total est en centimes entiers. Aucune décimale pour l'argent, nulle part, jamais.

La méta-règle : les exceptions sont écrites

Remarquez ce que les trois exceptions ont en commun. Chacune a un déclencheur étroit (forme inconnaissable ; coût mesuré du calcul en direct ; nature de l'argent). Chacune a un mécanisme compensatoire (le test du JOIN ; les triggers de synchronisation ; la conversion dans la couche d'affichage). Et chacune est documentée — ma plateforme tient un fichier de décisions de conception qui liste chaque écart intentionnel, précisément pour que les audits futurs (humains ou IA) puissent distinguer l'ingénierie délibérée du laisser-aller accumulé.

C'est la vraie différence entre une entorse professionnelle et de la dette technique : l'une vient avec une raison écrite, l'autre avec un haussement d'épaules.

Le livreThe Solopreneur RevolutionLuis Gonçalves sur la création d'une activité de solopreneur avec l'IA, sans quitter son emploi.Obtenir le livre →

Questions fréquentes

Le JSONB est-il une mauvaise pratique ?

Non — c'est le JSONB mal utilisé qui est une mauvaise pratique. Pour des données vraiment flexibles et propres à une ligne, c'est le bon outil et il évite une complexité inutile. Le mode d'échec, c'est de l'utiliser pour esquiver la conception de la base : fourrer des tags, des assignés ou des relations dans un blob JSON parce que concevoir les bonnes tables paraissait du travail. Appliquez le test du JOIN et le JSONB reste un outil au lieu d'un piège.

Comment savoir quand un compteur doit être stocké ?

Quand le comptage en direct fait mesurablement mal — une page qui recompte de gros ensembles d'enregistrements à chaque affichage — et pas avant. Commencez par calculer les nombres à la demande ; ne stockez un compteur que lorsque l'échelle l'impose, et jamais sans le trigger ou la fonction qui le maintient exact. Les compteurs prématurés sont une complexité imméritée.

Pourquoi ne pas simplement utiliser une colonne décimale pour l'argent ?

Parce que les centimes entiers rendent impossible, et non simplement improbable, toute une classe de bugs financiers, et parce que votre prestataire de paiement pense déjà en plus petites unités monétaires. Deux représentations de l'argent — des centimes chez Stripe, des décimales dans votre base — signifient des conversions partout, et chaque conversion est une occasion de se tromper sur la facture de quelqu'un.

Que se passe-t-il si j'utilise le JSONB pour tout ?

Vous obtenez une base de données incapable de répondre aux questions. Pas de relations, pas de contrôle d'intégrité, pas de filtrage efficace, un reporting pénible — vous avez reconstruit un tas de documents avec des étapes en plus. Une flexibilité dont vous n'aviez pas besoin, achetée au prix de la capacité d'interrogation sur laquelle votre entreprise tourne. Gardez la structure pour les 95 % et dépensez le JSONB là où la forme est réellement inconnaissable.