Aujourd’hui, on va creuser un peu plus les tableaux et les comparer à JSONB, voir leurs points forts et faibles, et choisir les meilleures pratiques pour les utiliser dans des cas concrets.
Tableaux vs JSONB : mini-tortues de données vs flexibilité en boîte
Tu sais déjà que dans les tableaux PostgreSQL, tu peux stocker des valeurs d’un seul type de données : un tableau de nombres, de chaînes ou de dates. Exemple : une liste de notes d’étudiant, où tous les éléments sont des nombres.
-- Table avec les étudiants et leurs notes
CREATE TABLE students (
id SERIAL PRIMARY KEY,
name TEXT,
grades INTEGER[] -- tableau de notes
);
JSONB, contrairement au tableau, c’est du stockage de données sous forme de structure JSON. Ça ressemble beaucoup à un objet JavaScript, mais avec l’avantage d’un parsing rapide et de l’indexation. Dans JSONB, tu peux stocker des listes ordonnées ou des objets avec des clés et des valeurs.
-- Table avec les étudiants et différentes infos sur eux
CREATE TABLE students_details (
id SERIAL PRIMARY KEY,
name TEXT,
details JSONB -- structure JSON flexible
);
Exemple de données dans JSONB :
{
"grades": [90, 82, 77],
"address": {
"city": "Berlin",
"zip": "352912"
}
}
Donc, les tableaux — c’est une façon simple de gérer des listes de valeurs, alors que JSONB te donne beaucoup plus de possibilités pour des données complexes.
Principales différences entre tableaux et JSONB
| Caractéristique | Tableaux | JSONB |
|---|---|---|
| Type de structure | Structure de données linéaire | Structure de données hiérarchique |
| Types d’éléments | Un seul type de données | Types de données variés |
| Taille de la structure | Fixe (linéaire) | Flexible, peut inclure des listes et des objets |
| Vitesse d’accès | Rapide avec des données fixes | Plus lent pour des recherches complexes |
| Indexation | Bonne prise en charge de l’indexation | Nécessite une indexation de type GIN |
| Utilisation | Liste simple ou tableau de valeurs | Données complexes : objets/listes imbriqués |
Voyons maintenant comment ça marche en pratique.
Quand utiliser les tableaux ?
Imaginons qu’on a une base de données de livres, où chaque livre peut appartenir à plusieurs genres. Ici, le tableau est un bon choix.
CREATE TABLE books (
id SERIAL PRIMARY KEY,
title TEXT,
genres TEXT[] -- tableau de genres
);
-- Exemple d’insertion d’un livre avec plusieurs genres
INSERT INTO books (title, genres)
VALUES ('1984', ARRAY['Dystopia', 'Political Fiction', 'Science Fiction']);
Les tableaux sont cool si tu es sûr que :
- tes données peuvent être stockées strictement comme une liste,
- les listes seront petites et homogènes (genre chaînes ou nombres),
- tu veux juste stocker et récupérer des listes (sans opérations complexes).
Avantages des tableaux
- Simplicité pour stocker des données du même type.
- Pratiques pour les petites listes, comme des tags, catégories ou notes.
Quand utiliser JSONB ?
Maintenant, imaginons qu’on veut stocker des infos plus complexes sur les livres, comme les genres, l’ISBN et la note. Là, les tableaux ne suffisent plus — c’est le moment de sortir JSONB.
CREATE TABLE books_details (
id SERIAL PRIMARY KEY,
title TEXT,
details JSONB -- détails du livre en JSONB
);
-- Exemple d’insertion d’infos complexes sur un livre
INSERT INTO books_details (title, details)
VALUES (
'1984',
'{"genres": ["Dystopia", "Political Fiction", "Science Fiction"],
"isbn": "9780451524935",
"rating": 8.9}'
);
JSONB est top si tu dois :
- stocker des données complexes ou hétérogènes (nombres, chaînes, listes, objets),
- ajouter dynamiquement des paramètres sans changer la structure de la table,
- gérer des données imbriquées (genre adresses, caractéristiques, settings).
Avantages de JSONB
- Super flexible. Tu peux ajouter de nouvelles clés et valeurs sans toucher à la structure de la table.
- Parfait pour stocker des données complexes, genre des réponses JSON d’API.
Choisir entre tableaux et JSONB
Si tu dois juste stocker des listes de données homogènes — prends les tableaux. Par exemple :
-- Stocker les ID des participants à des événements
CREATE TABLE events (
id SERIAL PRIMARY KEY,
participant_ids INTEGER[]
);
Si les données sont hétérogènes ou complexes — mieux vaut utiliser JSONB. Par exemple :
-- Stocker des infos clients avec adresses
CREATE TABLE customers (
id SERIAL PRIMARY KEY,
info JSONB
);
Pour l’indexation, tableaux et JSONB ont des approches différentes. Pour les tableaux, on utilise souvent les index GIN, et pour JSONB — GIN et BTREE, selon la structure des données.
Performance
Les tableaux sont plus rapides pour les recherches classiques. JSONB est un peu plus lent, mais il gagne en flexibilité. Si tu veux juste chercher des éléments (genre des genres ou des ID), les tableaux seront plus rapides :
-- Utilisation des tableaux avec un index GIN
CREATE INDEX idx_genres ON books USING GIN(genres);
-- Filtrer les livres par genre
SELECT * FROM books WHERE genres @> ARRAY['Science Fiction'];
Vérification de la présence de données
Avec JSONB, t’as plus d’options pour filtrer par clés :
-- Vérifier la présence de la clé "genres"
SELECT * FROM books_details WHERE details ? 'genres';
-- Vérifier la présence d’un élément dans la liste
SELECT * FROM books_details WHERE details->'genres' ?| ARRAY['Fantasy', 'Dystopia'];
Les tableaux permettent de chercher des valeurs direct :
-- Vérifier la présence d’un élément dans le tableau
SELECT * FROM books WHERE genres @> ARRAY['Fantasy'];
Flexibilité des structures
JSONB est imbattable si tes données sont complexes et imbriquées :
{
"genres": ["Fantasy", "Adventure"],
"ratings": {"goodreads": 8.5, "amazon": 4.7}
}
Pour les tableaux, c’est impossible sans normalisation ou champs supplémentaires.
Au final, tableaux et JSONB — ce ne sont pas des concurrents, mais des outils pour des besoins différents. Si tes données ressemblent à une liste — prends les tableaux. Si c’est complexe, imbriqué ou hétérogène — fonce sur JSONB. Le plus important, c’est de penser à la perf et à l’indexation !
GO TO FULL VERSION