Jeg skal bruge nogle forespørgsler i formen "liste alle objekter, hvor et af altnavnene er 'foobar'." Den forventede tabelstørrelse er i størrelsesordenen nogle få millioner poster. Postgres JSON-forespørgsler kan bruges til det, og det kan også indekseres (Index For Finding Element i JSON-array, for eksempel). BØR det dog gøres på den måde, eller er det en pervers løsning, der ikke anbefales?
Det kan gøres på den måde, men det betyder ikke, at du skal. I en vis forstand er den bedste praksis allerede veldokumenteret (se f.eks. brug af hstore vs brug af XML vs brug af EAV vs brug af en separat tabel) med en ny datatype, som for alle hensigter og praktiske formål (udover validering og syntaks) ikke er anderledes fra tidligere ustrukturerede eller semistrukturerede muligheder.
Sagt på en anden måde er det den samme gamle gris med ny makeup.
JSON tilbyder muligheden for at bruge inverterede søgetræindekser , på samme måde som hstore, array-typer og tsvectors gør. De fungerer fint, men husk på, at de primært er designet til at udtrække punkter i et nabolag (tænk på geometrityper) ordnet efter afstand, snarere end til at udtrække en liste med værdier i leksikografisk rækkefølge.
For at illustrere, tag de to planer, som Romans svar skitserer:
- Den, der laver en indeksscanning pløjer direkte gennem disksider og henter rækkerne i den rækkefølge, som indekset angiver.
- Den, der foretager en bitmap-indeksscanning starter med at identificere hver diskside, der kan indeholde en række, og læser dem, som de vises på disken, som om den lavede (og faktisk præcis ligesom) en sekvensscanning, der springer ubrugelige områder over.
Tilbage til dit spørgsmål:rodet og overdimensionerede omvendte træindekser vil faktisk forbedre ydeevnen af din app, hvis du bruger Postgres-tabeller som gigantiske JSON-butikker. Men de er heller ikke en sølvkugle, og de vil ikke bringe dig så langt som korrekt relationelt design, når du håndterer flaskehalse.
Bundlinjen er i sidste ende ikke anderledes end, hvad du ville få, når du beslutter dig for at bruge hstore eller en EAV:
- Hvis det har brug for et indeks (dvs. det vises ofte i en where-klausul eller, endnu vigtigere, i en join-klausul), vil du sandsynligvis have dataene i et separat felt.
- Hvis det primært er kosmetisk, fungerer JSON/hstore/EAV/XML/whatever-making-you-sleep-at-night fint.