En la mayoría de los casos, usaría un esquema normalizado
con una tabla option_tag implementando la relación de muchos a muchos entre las tablas option y tag . Implementación de referencia aquí:
Puede que no sea la opción más rápida en todos los aspectos, pero ofrece la gama completa de funciones de base de datos, incluida la integridad referencial, las restricciones, la gama completa de tipos de datos, todas las opciones de índice y actualizaciones económicas.
Para completar, agregue a su lista de opciones:
hstore(buena opción)xmlmás detallado y más complejo quehstoreojsonb, por lo que solo lo usaría cuando opere con XML.- "cadena de valores separados por comas" (opción muy simple, en su mayoría mala)
- EAV (Entidad-Atributo-Valor) o "pares de nombre-valor" (en su mayoría mala opción)
Detalles bajo esta pregunta relacionada en dba.SE:
Si la lista es solo para mostrar y rara vez se actualiza, consideraría una matriz simple, que generalmente es más pequeña y funciona mejor para esto que el resto.
Lea la entrada de blog de Josh Berkus @a_horse vinculado en su comentario. Pero tenga en cuenta que se centra en casos de lectura seleccionados. Josh reconoce:
Y ahí es donde el enfoque normalizado gana en grande, especialmente cuando cambias mucho las etiquetas individuales bajo carga simultánea.
jsonb es solo una buena opción si va a operar con JSON de todos modos, y puede almacenar y recuperar JSON "tal cual".
