JSONB, partitionnement et évolution de schéma

Comprendre le mécanisme

JSON conserve une représentation textuelle validée ; JSONB organise les données dans une représentation exploitable pour des recherches et index spécifiques. Les deux choix ont des comportements différents, notamment sur la représentation du document. Un document JSON valide ne garantit pas le schéma métier. Les relations, clés et valeurs fréquemment interrogées peuvent mériter des colonnes relationnelles explicites plutôt qu’un document opaque.

Raisonner et vérifier

Le partitionnement organise physiquement de grands ensembles selon une clé et des règles ; il ne remplace pas la conception des accès ni tous les index. Pour faire évoluer un schéma utilisé par plusieurs versions d’application, séparez ajout compatible, transition du code et retrait ultérieur. Mesurez les verrous et le coût d’une migration sur un jeu représentatif, puis définissez la reprise si elle échoue.

Une représentation JSONB n’est pas le texte initial

JSONB organise un document selon une représentation propre au moteur. Ne supposez pas qu’il conserve tous les espaces ou détails textuels du message reçu. Si vous devez authentifier des octets bruts, cette exigence doit être traitée avant une transformation qui change leur représentation. Distinguez identité de contenu métier et identité d’octets ; les deux propriétés peuvent servir à des contrôles différents.

La syntaxe ne définit pas le schéma métier

Un document valide peut manquer amount, porter une chaîne au lieu d’un entier ou contenir des combinaisons interdites. Après parsing, appliquez les règles de présence, de type et de relation prévues par le domaine. Les tests doivent viser ces distinctions. Une base capable de stocker le document n’a pas automatiquement décidé qu’il représente une commande acceptable pour l’application.

Absence et valeur null

Une clé présente avec JSON null peut signifier autre chose qu’une clé absente. Pour une mise à jour partielle, l’une pourrait demander un effacement tandis que l’autre signifie conserver la valeur, selon votre contrat. Vérifiez les opérateurs choisis et l’interprétation applicative. Une comparaison visuelle des documents ne suffit pas : écrivez le résultat attendu pour chaque état et testez leur lecture et transformation.

Indexer selon les opérateurs utiles

Un index JSON doit correspondre aux opérations et expressions des requêtes à accélérer. Le simple fait qu’un index concerne un document ne garantit pas l’accès efficace à toute extraction possible. Définissez les recherches importantes et mesurez leur plan avec des données représentatives. Conservez d’abord les assertions de résultat, car une optimisation de structure ne doit pas modifier la sémantique de présence, de type ou de filtrage.

Combiner données relationnelles et documents

Un identifiant métier utilisé pour des relations ou une contrainte importante peut bénéficier d’une colonne relationnelle explicite. Le format JSON ne dispense pas de garantir l’unicité et les références utiles au domaine. Choisissez quelles informations ont une responsabilité stable dans le schéma et quelles parties restent documentaires. Une séparation cohérente aide les consommateurs à comprendre les garanties, plutôt que cacher tout invariant dans une chaîne générale.

Lire les anciennes versions

Ajouter un champ attendu par une nouvelle application ne le crée pas dans les documents historiques. Définissez comment les consommateurs lisent un ancien format et comment les données sont migrées. Un défaut de lecture choisi doit avoir un sens métier clair ; une valeur arbitraire peut masquer un cas impossible. Préparez des fixtures d’avant et d’après l’évolution afin de vérifier réellement cette compatibilité.

Élargir, migrer, retirer

Quand deux versions d’application peuvent être actives, une modification brutale de format peut casser l’une d’elles. Une stratégie progressive ajoute d’abord une capacité compatible, migre les usages et données, puis retire l’ancien contrat une fois le périmètre maîtrisé. Cette séquence demande des critères observables, pas seulement trois noms d’étapes. Testez les deux consommateurs pendant la transition et la reprise après un incident intermédiaire.

Convertir une extraction selon son contrat

Une extraction textuelle peut contenir autre chose qu’un nombre valide. Avant un cast, définissez la grammaire et les bornes admises, puis traitez le refus. Le stockage JSON ne fournit pas automatiquement la bonne conversion pour chaque domaine. Un texte numérique très grand peut aussi dépasser une représentation choisie par l’application. Si seuls ses chiffres importent, le contrat peut demander de le conserver comme texte.

Les droits ne changent pas avec le format

Une donnée personnelle reste sensible lorsqu’elle est stockée dans JSONB. Les règles d’accès doivent porter sur le document et les opérations permises, avec le contexte de tenant approprié. Un champ imbriqué ne devient pas public parce qu’il échappe à une colonne relationnelle dédiée. Testez les réponses effectivement renvoyées et la minimisation des extractions, notamment sur les endpoints de recherche et les exports.

Tester les cas qui changent d’interprétation

Une évolution de document doit être vérifiée sur clés absentes, nulls, mauvais types et valeurs limites, ainsi que sur le nominal. Écrivez les résultats attendus avant la conversion. Ces catégories révèlent souvent une différence entre ancienne et nouvelle version qui reste invisible sur un seul document complet. Le test doit aussi vérifier l’absence d’effet sur une entrée refusée, pas seulement une exception affichée.

Atelier guidé : lire, expliquer et vérifier le code

SELECT
    '{"amount":null}'::jsonb ? 'amount' AS present,
    '{}'::jsonb ? 'amount' AS absent;

L’opérateur montré teste la présence d’une clé. Dans le premier document, amount existe même si sa valeur est JSON null ; le résultat est vrai. Dans le second, la clé est absente et le résultat est faux. La fixture démontre donc une différence de structure, pas une décision automatique sur la validité métier d’un montant.

Définissez ensuite un contrat de modification partielle et attribuez un sens à chacune de ces situations. Ajoutez un document où amount porte une chaîne invalide. Vérifiez la lecture, la conversion éventuelle et le refus avant écriture. Une bonne migration doit conserver cette distinction tant que les deux formats existent ; traiter toutes les absences comme zéro pourrait modifier silencieusement le sens de données historiques.