Ve většině případů bych použil normalizované schéma
s tabulkou option_tag implementace vztahu many-to-many mezi tabulkami option a tag . Referenční implementace zde:
Nemusí to být nejrychlejší volba ve všech ohledech, ale nabízí celou řadu funkcí DB, včetně referenční integrity, omezení, celé řady datových typů, všech možností indexu a levných aktualizací.
Pro úplnost přidejte do seznamu možností:
hstore(dobrá volba)xmlpodrobnější a složitější nežhstorenebojsonb, takže bych jej používal pouze při práci s XML.- "řetězec hodnot oddělených čárkami" (velmi jednoduchá, většinou špatná možnost)
- EAV (Entity-Attribute-Value) nebo "páry název-hodnota" (většinou špatná volba)
Podrobnosti pod touto související otázkou na dba.SE:
Pokud je seznam pouze pro zobrazení a zřídka se aktualizuje, uvažoval bych o obyčejném poli, které je obvykle menší a funguje lépe než ostatní.
Přečtěte si příspěvek na blogu od Joshe Berkuse @a_horse odkazoval ve svém komentáři na. Uvědomte si ale, že se zaměřuje na vybrané případy čtení. Josh připouští:
A v tom vyhrává normalizovaný přístup, zvláště když hodně měníte jednotlivé tagy při současném zatížení.
jsonb je to dobrá volba pouze v případě, že se přesto chystáte pracovat s JSON a můžete ukládat a načítat JSON "tak, jak je".