In den meisten Fällen würde ich ein normalisiertes Schema
verwenden mit einer Tabelle option_tag Implementieren der Viele-zu-Viele-Beziehung zwischen den Tabellen option und tag . Referenzimplementierung hier:
Es ist vielleicht nicht in jeder Hinsicht die schnellste Option, aber es bietet die volle Bandbreite der DB-Funktionalität, einschließlich referentielle Integrität, Constraints, die volle Bandbreite an Datentypen, alle Indexoptionen und günstige Updates.
Ergänzen Sie der Liste der Optionen der Vollständigkeit halber:
hstore(gute Option)xmlausführlicher und komplexer als beidehstoreoderjsonb, also würde ich es nur verwenden, wenn ich mit XML arbeite.- "String aus kommagetrennten Werten" (sehr einfache, meist schlechte Option)
- EAV (Entity-Attribute-Value) oder "Name-Value-Paare" (meistens schlechte Option)
Details unter dieser verwandten Frage auf dba.SE:
Wenn die Liste nur zur Anzeige dient und selten aktualisiert wird, würde ich ein einfaches Array in Betracht ziehen, das normalerweise kleiner ist und dafür eine bessere Leistung als der Rest erbringt.
Lesen Sie den Blogeintrag von Josh Berkus @a_horse in seinem Kommentar verlinkt. Beachten Sie jedoch, dass es sich auf ausgewählte Lesefälle konzentriert. Josh räumt ein:
Und hier gewinnt der normalisierte Ansatz, besonders wenn Sie einzelne Tags häufig unter gleichzeitiger Last ändern.
jsonb ist nur dann eine gute Option, wenn Sie ohnehin mit JSON arbeiten und JSON "wie besehen" speichern und abrufen können.
