PostgreSQL prend en charge les colonnes de tableau — une seule colonne peut contenir plusieurs valeurs du même type. C'est une fonctionnalité distinctive de Postgres utile pour stocker des listes (tags, rôles, scores) sans table séparée, avec des opérateurs et des fonctions pour interroger.
posts (
id SERIAL ,
title TEXT,
tags TEXT[]
);
posts (title, tags)
(, [, ]),
(, );
La syntaxe type[] déclare une colonne de tableau. Vous insérez avec la syntaxe ARRAY[...] ou les littéraux '{...}'.
-- ANY — does the array contain a value?
SELECT * FROM posts WHERE 'ruby' = ANY(tags);
-- @> containment — does the array contain ALL of these?
SELECT * FROM posts WHERE tags @> ARRAY['ruby', 'web'];
-- && overlap — do the arrays share ANY element?
SELECT * FROM posts WHERE tags && ARRAY['tech', 'news'];
-- access by index (1-based!) and length
SELECT tags[1], array_length(tags, 1) FROM posts;
-- unnest — expand an array into rows
SELECT id, unnest(tags) AS tag FROM posts; -- one row per tag
Les opérateurs comme ANY (contient une valeur), @> (contenance), et && (chevauchement), plus les fonctions comme unnest (développer en lignes) et array_agg (agréger les lignes en tableau), rendent les tableaux interrogeables.
-- a GIN index makes array containment/membership queries fast
CREATE INDEX idx_posts_tags ON posts USING GIN (tags);
-- now WHERE tags @> ARRAY['ruby'] uses the index
✓ USE for: simple lists tightly coupled to the row (tags, roles, a few scores)
where you don't need to query/join the individual values much
✗ AVOID when: you need to query, join, or maintain the values relationally,
or the list is large/complex → a separate related table (normalized) is better
→ Arrays are convenient but can violate normalization; use them judiciously.
Les colonnes de tableau sont une fonctionnalité distinctive et utile de PostgreSQL, et les comprendre a de la valeur à la fois pour exploiter les capacités de Postgres et pour prendre des décisions de conception judicieuses.
Les tableaux vous permettent de stocker plusieurs valeurs dans une seule colonne (tags, rôles, listes) sans table séparée — pratique pour les listes simples étroitement couplées à une ligne.
Comprendre comment définir, insérer et surtout interroger les tableaux (opérateurs comme ANY pour l'appartenance, @> pour la contenance, && pour le chevauchement, et les fonctions comme unnest pour développer les tableaux en lignes) est nécessaire pour les utiliser efficacement, et savoir que les indexes GIN rendent les requêtes sur tableaux efficaces est important pour les performances.
Également important est le jugement de conception de savoir quand utiliser les tableaux par rapport à une table connexe normalisée : les tableaux sont pratiques pour les listes simples que vous n'avez pas besoin d'interroger, de joindre ou de maintenir relationnellement, mais ils peuvent violer les principes de normalisation et devenir maladroits quand vous avez besoin d'interroger des valeurs individuelles, de les joindre, ou de gérer une liste complexe/grande — auquel cas une table connexe séparée est le meilleur choix, normalisé.
Comprendre ce compromis (les tableaux pour la commodité avec des listes couplées simples, les tables séparées pour les données gérées relationnellement) reflète un jugement de conception judicieux.
Comme les tableaux sont une fonctionnalité Postgres utile et distinctive qui peut simplifier certaines conceptions (éviter une table de jonction pour les listes simples) mais peuvent être mal utilisées (dénormaliser les données qui devraient être relationnelles), comprendre les colonnes de tableau — comment les définir, les interroger et les indexer, et surtout quand elles sont appropriées par rapport au moment où une table normalisée est meilleure — est une connaissance précieuse et pratiquement pertinente pour concevoir des schémas Postgres qui utilisent la bonne approche pour chaque type de données multivalorées.