Réponse.

Historique de la question

Le SQL classique ne permet pas de stocker plusieurs valeurs dans une seule cellule — le modèle relationnel exige une normalisation. Cependant, dans des tâches modernes, on rencontre souvent des champs de type "liste de tags", "échelle de notes", où il est pratique de manipuler un ensemble de valeurs au niveau d'une ligne individuelle. Certaines SGBD (PostgreSQL, Oracle) fournissent des types de données ARRAY ou des mécanismes similaires.

Problème

L'utilisation de tableaux viole le principe de normalisation, complique de nombreuses opérations (filtrage, mise à jour, indexation), et rend également le code moins portable entre les SGBD. Mais cela peut s'avérer utile ou inévitable — par exemple, pour le caching ou la recherche rapide dans de petites listes de valeurs.

Solution

Dans PostgreSQL, le support des tableaux est natif. Exemple :

CREATE TABLE products (
  id SERIAL PRIMARY KEY,
  tags TEXT[]
);

-- Insertion :
INSERT INTO products(tags) VALUES (ARRAY['eco','sale','hot']);

-- Recherche dans un tableau :
SELECT * FROM products WHERE 'eco' = ANY (tags);

Dans MySQL 5.x, il n'y a pas de tableaux, on utilise souvent JSON ou des chaînes séparées et des fonctions pour l'analyse.
Dans Oracle — collections, nested table/varray.
Pour des tâches analytiques optimales, il est préférable de normaliser (créer une table secondaire liée product_tags) et d'utiliser JOIN, et de stocker le tableau uniquement dans des cas particuliers (performance ou exigences spécifiques).

Caractéristiques clés :

Pratique lorsque le tableau est réellement nécessaire et que le SGBD le supporte.
Problèmes avec les index et le filtrage lors de l'utilisation de grands tableaux.
Non portable entre les SGBD, complique la maintenance.

Questions pièges.

Peut-on indexer des éléments individuels d'un tableau ?

Dans PostgreSQL — oui, via des index GIN/GIST :

CREATE INDEX idx_tags ON products USING GIN (tags);

Comment vérifier rapidement l'appartenance d'une valeur dans un tableau dans une colonne de chaîne via un séparateur ?

Le SQL standard ne le permet pas, on utilise une recherche par modèle :

SELECT * FROM users WHERE ',admin,' like concat('%,',role,',%');

Mais cette approche est peu fiable et lente.

Combien de valeurs peut-on stocker dans un tableau, et qu'est-ce qui limite cela ?

La limite dépend du SGBD — par exemple, dans PostgreSQL, il n'y a qu'une limite sur la taille de la chaîne (1–2 Mo).

Erreurs typiques et anti-patterns

Stocker des tableaux dans une seule cellule pour des raisons de "simplicité" et compliquer l'analyse.
Filtrer incorrectement des valeurs via LIKE sans tenir compte des séparateurs.
Compter sur l'unicité et l'indexation des chaînes-tableaux.

Exemple de la vie réelle

Cas négatif

Dans un projet e-commerce, les tags de produits ont été stockés sous forme de chaîne séparée par des virgules dans une seule colonne. La recherche rapide des produits par tag était très compliquée, des erreurs de filtrage se produisaient, et la répétition des tags arrivait à cause d'erreurs de parsing.

Avantages :

"Simple" et rapidement réalisable.

Inconvénients :

Très lent à grande échelle, difficile à maintenir, impossible de garantir l'unicité des valeurs.

Cas positif

Dans PostgreSQL, pour de petites ensembles immuables (rôles d'utilisateur), on a utilisé ARRAY et un index GIN. Pour les plus grands — une table de rôles séparée.