Dans la plupart des cas, j'utiliserais un schéma normalisé
avec un tableau option_tag implémenter la relation plusieurs à plusieurs entre les tables option et tag . Implémentation de référence ici :
Ce n'est peut-être pas l'option la plus rapide à tous égards, mais elle offre toute la gamme des fonctionnalités de base de données, y compris l'intégrité référentielle, les contraintes, la gamme complète de types de données, toutes les options d'index et les mises à jour bon marché.
Pour être complet, ajoutez à votre liste d'options :
hstore(bonne option)xmlplus verbeux et plus complexe quehstoreoujsonb, donc je ne l'utiliserais que lorsque j'utiliserais XML.- "chaîne de valeurs séparées par des virgules" (option très simple, généralement mauvaise)
- EAV (Entity-Attribute-Value) ou "paires nom-valeur" (principalement une mauvaise option)
Détails sous cette question connexe sur dba.SE :
Si la liste est juste pour l'affichage et rarement mise à jour, je considérerais un tableau simple, qui est généralement plus petit et fonctionne mieux pour cela que le reste.
Lisez l'entrée de blog par Josh Berkus @a_horse lié à dans son commentaire. Mais sachez qu'il se concentre sur des cas de lecture sélectionnés. Josh concède :
Et c'est là que l'approche normalisée gagne gros, en particulier lorsque vous modifiez beaucoup de balises uniques sous une charge simultanée.
jsonb n'est une bonne option que si vous allez de toute façon opérer avec JSON, et que vous pouvez stocker et récupérer JSON "tel quel".
