Nella maggior parte dei casi userei uno schema normalizzato
con una tabella option_tag implementando la relazione molti-a-molti tra le tabelle option e tag . Fare riferimento all'implementazione qui:
Potrebbe non essere l'opzione più veloce sotto ogni aspetto, ma offre l'intera gamma di funzionalità DB, inclusi integrità referenziale, vincoli, l'intera gamma di tipi di dati, tutte le opzioni di indice e aggiornamenti economici.
Per completezza, aggiungi al tuo elenco di opzioni:
hstore(buona opzione)xmlpiù dettagliato e più complesso di entrambihstoreojsonb, quindi lo userei solo quando si opera con XML.- "stringa di valori separati da virgole" (opzione molto semplice, per lo più errata)
- EAV (Entity-Attribute-Value) o "coppie nome-valore" (opzione per lo più errata)
Dettagli sotto questa domanda correlata su dba.SE:
Se l'elenco è solo per la visualizzazione e viene aggiornato raramente, prenderei in considerazione un semplice array, che in genere è più piccolo e offre prestazioni migliori rispetto agli altri.
Leggi il articolo del blog di Josh Berkus @a_horse collegato a nel suo commento. Ma tieni presente che si concentra su casi di lettura selezionati. Josh ammette:
Ed è qui che l'approccio normalizzato vince alla grande, specialmente quando modifichi molto i singoli tag sotto carico simultaneo.
jsonb è solo una buona opzione se hai intenzione di operare comunque con JSON e puoi archiviare e recuperare JSON "così com'è".
