Erreurs courantes lors du travail avec des données JSON et comment les éviter

Travailler avec des données JSON dans PostgreSQL, c’est super puissant, mais comme tout outil, faut faire gaffe. Même une petite boulette peut transformer ta requête en vrai casse-tête. Aujourd’hui, on va encore se concentrer sur les erreurs classiques qui arrivent quand tu manipules JSON et JSONB dans PostgreSQL, et surtout comment les éviter.

Problème 1 : utiliser JSON au lieu de JSONB

Plein de débutants se plantent en prenant le type JSON, pensant que c’est le meilleur choix pour stocker des données au format JSON. Mais JSON dans PostgreSQL garde les données en texte, ce qui peut ralentir grave les recherches ou les filtres.

Exemple d’erreur :

CREATE TABLE products (
    id SERIAL PRIMARY KEY,
    details JSON
);

INSERT INTO products (details) VALUES ('{"nom": "Ordinateur portable", "prix": 1000}');

INSERT INTO products (details) VALUES ('{"nom": "Ordinateur portable", "prix": 1000}');

Si tu veux filtrer sur la clé (prix), ça va être bien plus lent qu’avec JSONB.

Comment corriger : utilise JSONB si tu comptes filtrer ou accéder souvent aux données.

CREATE TABLE products (
    id SERIAL PRIMARY KEY,
    details JSONB
);

Problème 2 : pas d’index sur JSONB

JSONB, c’est ultra puissant, mais sans index, les requêtes un peu velues peuvent ramer sévère.

Exemple d’erreur : imaginons qu’on a une table avec une colonne details où on stocke plein d’objets JSON :

SELECT * FROM products WHERE details->>'nom' = 'Ordinateur portable';

Si t’as pas mis d’index, le serveur va scanner toute la table (full table scan), et ça va prendre un temps fou.

Comment corriger : crée un index GIN pour accélérer la recherche sur les clés :

CREATE INDEX idx_details_nom ON products USING gin (details jsonb_path_ops);

Problème 3 : erreurs lors de l’extraction de données imbriquées

Extraire des données d’objets ou de tableaux imbriqués, ça peut vite devenir galère, surtout si tu piges pas la différence entre les opérateurs -> et ->>.

Exemple d’erreur :

SELECT details->'prix' FROM products;

Cette requête va te renvoyer la valeur au format JSON, pas une chaîne ("1000" au lieu de 1000). Si tu veux juste la valeur, faut utiliser ->> :

SELECT details->>'prix' FROM products;

Problème 4 : Mauvaise utilisation des opérateurs

Tu as peut-être croisé l’opérateur @> et tu t’es dit : "Ça a l’air cool, je vais l’utiliser tout le temps !" Mais si tu piges pas comment il marche, tu risques d’avoir des résultats chelous.

Exemple d’erreur :

SELECT * FROM products WHERE details @> '{"prix": 1000}';

Cette requête ne marche que si prix est un nombre dans le JSON. Si la valeur est stockée comme chaîne "1000", ça ne renverra rien.

Comment corriger : fais gaffe aux types de données dans le JSON :

SELECT * FROM products WHERE details->>'prix' = '1000';

Problème 5 : Gros objets JSON

Stocker de gros objets JSON sans optimisation peut vraiment ralentir tes requêtes. En plus, lire ou modifier même une petite partie d’un JSONB oblige à traiter tout l’objet.

Comment corriger : si certaines clés sont souvent utilisées, mets-les dans des colonnes séparées. Par exemple :

ALTER TABLE products ADD COLUMN prix NUMERIC;
UPDATE products SET prix = (details->>'prix')::NUMERIC;

Maintenant tu peux filtrer et trier efficacement sans devoir parser le JSONB à chaque fois.

Problème 6 : Reconstruction complète des objets lors des modifs

Quand tu utilises des fonctions comme jsonb_set() ou jsonb_insert(), PostgreSQL crée un nouvel objet JSONB à chaque fois, et ça peut coûter cher en perfs.

Comment corriger : réduis au max le nombre de mises à jour sur le JSONB. Par exemple, au lieu de faire plein de updates, regroupe tout dans une seule requête :

UPDATE products
SET details = jsonb_set(details, '{prix}', '1500'::jsonb);

Problème 7 : mauvaise compréhension de la structure des tableaux

Avec JSONB, les tableaux demandent aussi de l’attention. Imaginons que t’as un tableau :

{
    "tags": ["électronique", "ordinateur portable", "promo"]
}

Tu veux checker si le tag "ordinateur portable" est là. Si tu utilises mal l’opérateur @>, tu risques de rien trouver, parce qu’il attend un tableau, pas une chaîne.

Exemple d’erreur :

SELECT * FROM products WHERE details->'tags' @> '"ordinateur portable"';

Comment corriger : Utilise le bon format avec l’opérateur @> :

SELECT * FROM products WHERE details->'tags' @> '["ordinateur portable"]';

Conseils pour éviter les erreurs

Pour éviter plein de galères avec JSONB, suis ces conseils :

Choisis le bon type de données. Si tu bosses avec beaucoup de données et que tu filtres souvent, prends toujours JSONB au lieu de JSON.

Indexe tes données. Si tes requêtes tapent souvent sur certaines clés, crée un index adapté (genre GIN).

Vérifie les données avant d’insérer. Utilise des fonctions de validation pour checker la structure des données :

DO $$
BEGIN
    IF jsonb_typeof('{"prix": 1000}'::jsonb->'prix') IS DISTINCT FROM 'number' THEN
        RAISE EXCEPTION 'Le prix doit être un nombre';
    END IF;
END $$;

Optimise la structure de tes données. Si certaines clés sont plus utilisées que d’autres, mets-les dans des colonnes séparées.

Apprends les opérateurs et fonctions. Lis bien la doc officielle PostgreSQL pour bien piger la différence entre ->, ->>, @>, ?|, et les autres fonctions.

JSON et JSONB peuvent devenir tes meilleurs potes pour gérer des données flexibles et complexes. Le plus important, c’est de bien choisir tes outils et d’éviter les erreurs classiques, pour que ton code soit efficace et facile à maintenir.