Mens du oppretter en tabell, vil du ha to alternativer for JSON -kolonnen din. Vanlig JSON -datatype og JSONB -datatype, begge har sine egne fordeler og ulemper. Vi skal gå gjennom hver av dem, ved å lage en enkel tabell med bare 2 kolonner en ID og en JSON -verdi. Etter dette vil vi spørre data fra tabellen og få en følelse av hvordan du administrerer JSON -formaterte data i Postgres.
JSON -datatype
Opprette en tabell med JSON -datatype
La oss lage en enkel to kolonnebord som heter brukere:
Lag tabellbrukere (Her fungerer kolonne -IDen som den primære nøkkelen, og den vil øke på en trinnvis måte takket være pseudotypeserien, slik at vi ikke trenger å bekymre oss for å legge inn verdier for ID manuelt når vi går sammen.
Den andre kolonnen er av JSON -typen og blir tvunget til å ikke være null. La oss legge inn noen få rader med data til denne tabellen, bestående av JSON -verdier.
Sett inn i brukere (info) verdier (Du kan bruke din foretrukne JSON Beautifier/minifier for å konvertere JSON -nyttelasten ovenfor til en enkelt linje. Så du kan lime den på en gang i PSQL -ledeteksten.
Velg * fra brukere;Select -kommandoen på slutten viste oss at radene ble satt inn i brukertabellen med hell.
Spørring av JSON -datatype
Postgres lar deg grave i selve JSON -nyttelasten og hente en bestemt verdi ut av den, hvis du refererer til den ved å bruke den tilsvarende verdien. Vi kan bruke -> operatøren etter JSON -kolonnen navn, etterfulgt av nøkkelen inne i JSON -objektet. Ved å gjøre det
For eksempel i tabellen opprettet vi ovenfor:
Du har kanskje lagt merke til de doble sitatene i kolonnen som inneholder e -post. Dette er fordi -> Operatøren returnerer et JSON -objekt, som til stede i verdien av nøkkelen “E -post”. Selvfølgelig kan du returnere bare tekst, men du må bruke ->> operatøren i stedet.
Velg info ->> 'E -post' fra brukere;Forskjellen mellom å returnere et JSON -objekt og en streng blir klar når vi begynner å jobbe med JSON -objekter som er nestet inne i andre JSON -objekter. For eksempel valgte jeg "PersonalDetails" -tasten for å holde et annet JSON -objekt med vilje. Vi kan grave inn i dette objektet også, hvis vi vil:
Velg info -> 'PersonalDetails' -> 'kjønn' fra brukere;Dette kan la deg gå så dypt inn i JSON -objektet som du vil. La oss slippe denne tabellen og lage en ny (med samme navn), men med JSONB -type.
JSONB datatype
Bortsett fra at vi under opprettelsen av tabellen nevner JSONB -datatype i stedet for JSON, alt annet utseende det samme.
Lag tabellbrukere (Selv innsetting av data og henting ved bruk av -> operatøren oppfører seg på samme måte. Det som har endret seg er alt under panseret og merkes i bordets ytelse. Når du konverterer JSON -tekst til en JSONB, gjør Postgres faktisk de forskjellige JSON -verditypene til naturlig postgres -type, så ikke alle gyldige JSON -objekter kan lagres som gyldig JSONB -verdi.
Dessuten bevarer ikke JSONB hvitespasene, orden av JSON -nøkler som leveres av innsatserklæringen. JSONB konverterer faktisk nyttelasten til innfødte postgres binær, derav begrepet JSONB.
Selvfølgelig har innsetting av JSONB Datum en ytelsesoverhead på grunn av alt dette tilleggsarbeidet som Postgres trenger å gjøre. Fordelen du får er imidlertid når det.
JSON vs JSONB
Avgjørelsen mellom JSON og JSONB Sole avhenger av brukssaken din. Når du er i tvil, bruk JSONB, siden de fleste applikasjoner har en tendens til å ha hyppigere leseoperasjoner som skriver operasjoner. På den annen side, hvis du er sikker på at søknaden din forventes å gjøre mer synkrone skriveoperasjoner enn å lese, kan det være lurt å betrakte JSON som et alternativ.
Personer som jobber med JSON nyttelast og utforming av grensesnitt for lagring av postgres vil ha stor nytte av denne delen av deres offisielle dokumentasjon. Utviklerne var snille nok til å gi oss JSONB -indeksering og andre kule funksjoner som kan utnyttes for å forbedre ytelsen og enkelheten i applikasjonen din. Jeg ber deg også undersøke disse.
Forhåpentligvis fant du denne korte introduksjonen av saken nyttig og inspirerende.