Jag kommer att behöva några frågor i formen "lista alla objekt där ett av altnamnen är 'foobar'." Den förväntade tabellstorleken är i storleksordningen några miljoner poster. Postgres JSON-frågor kan användas för det, och det kan också indexeras (index för att hitta element i JSON-array, till exempel). Men BÖR det göras på det sättet eller är det en pervers lösning som inte rekommenderas?
Det kan göras på det sättet men det betyder inte att du ska göra det. I någon mening är den bästa praxis redan väl dokumenterad (se t.ex. att använda hstore vs att använda XML vs att använda EAV vs att använda en separat tabell) med en ny datatyp som, för alla avsikter och praktiska ändamål (förutom validering och syntax), inte är annorlunda från tidigare ostrukturerade eller semistrukturerade alternativ.
Med andra ord är det samma gamla gris med nytt smink.
JSON erbjuder möjligheten att använda inverterade sökträdindex , på samma sätt som hstore, arraytyper och tsvectors gör. De fungerar bra, men kom ihåg att de i första hand är utformade för att extrahera punkter i en stadsdel (tänk geometrityper) ordnade efter avstånd, snarare än för att extrahera en lista med värden i lexikografisk ordning.
För att illustrera, ta de två planerna som Romans svar beskriver:
- Den som gör en indexskanning plöjer igenom disksidor direkt och hämtar raderna i den ordning som anges av indexet.
- Den som gör en bitmappsindexskanning börjar med att identifiera varje disksida som kan innehålla en rad och läser dem när de visas på disken, som om det var (och faktiskt precis som) att göra en sekvenssökning som hoppar över värdelösa områden.
För att återgå till din fråga:Belamrade och överdimensionerade inverterade trädindex kommer verkligen att förbättra prestandan för din app om du använder Postgres-tabeller som gigantiska JSON-butiker. Men de är inte heller en silverkula, och de kommer inte att få dig så långt som korrekt relationsdesign när du hanterar flaskhalsar.
Summan av kardemumman, i slutändan, skiljer sig inte från vad du skulle få när du bestämmer dig för att använda hstore eller en EAV:
- Om det behöver ett index (dvs. det förekommer ofta i en where-klausul eller, ännu viktigare, i en join-klausul), vill du troligen ha informationen i ett separat fält.
- Om det i första hand är kosmetiskt fungerar JSON/hstore/EAV/XML/whatever-making-you-sleep-at-night bra.