Rails Best Practice - Vedvarende adresser i PostgreSQL

Utvidelsen ‘hstore’ implementerer ‘hstore’ datatype for lagring av sett med nøkkel / verdipar

Sammendrag: foreslå en løsning som tilbyr en konsistent, performant og pålitelig metode for lagring og henting av komplekse datatyper fra en SQL-database.

Applikasjonsplanlegging er et viktig og ofte oversett trinn i å bygge vellykkede webapplikasjoner. Rails-rammeverket gjør det så enkelt å lage og starte opp en applikasjon at det frister for utviklere å hoppe over planlegging og hoppe helt til utvikling. Å generere applikasjonskode før du planlegger domenet riktig kan føre til slurvete eller til og med misdannede applikasjoner. Tenk for eksempel på den beste metoden for å håndtere "adresse" -feltet i en applikasjon.

Hva står i en adresse?

Slik ser en typisk adresse ut i USA:

Adresse: [
Street: "123 Happy Days Lane" streng
By: "Wonderland" streng
Oppgi: “PA” streng
Glidelås: 10102 streng
]

Verdien "Adresse" består av en rekke nøkkel / verdipar, der verdien er en streng. Det er et veldig vanlig felt å se i applikasjoner. Så hva er den beste måten å representere "Adresse" -verdien i en SQL-database? For å finne ut av dette, la oss se på hva andre utviklere gjør i denne situasjonen.

Alternativ 1: Lagre verdien i et enkelt felt som en streng, for eksempel:

Adresse: “123 Happy Days Ln. Wonderland, PA 10102 ”

Dette er en dårlig løsning. Som vi har sett i avsnittet ovenfor, er en adresse en rekke nøkkel / verdipar. Å behandle adressen som ethvert annet skalfelt ville være inkonsekvent. Denne inkonsekvensen blir tydelig når vi ønsker å utvide søknaden på et tidspunkt i fremtiden. La oss si at vi ønsker å finne alle kundene fra en gitt “by” eller “stat”. Fordi hele verdien til "Adresse" har blitt klemt i en streng, er det ikke lenger en enkel måte å gjøre dette på.

Alternativ 2: Del "Adresse" -verdien i forskjellige felt og lagre disse feltene, for eksempel:

Gate: “123 Happy Days Ln”, by: “Wonderland”, delstat: “PA”, zip: “10102”

Her har vi løst vår forrige hypotetiske utvidelse av å finne alle kunder til en bestemt “by” eller “stat”. Imidlertid representerer vi nå "Adresse" -feltet som fire separate og distinkte felt når felt faktisk skal kombineres.

Alternativ 3: Lag en egen adressetabell og utenlandsk nøkkelforening

Flere blogginnlegg og StackOverflow-svar konkluderer med at den beste måten å lagre adresser i Rails er å bruke en egen modell og en tilhører forening. På denne måten kan en bruker- eller forretningsmodell ha_mange adresser og ikke være begrenset til en enkelt adresse. Adressene vil også bli lagret på riktig måte, da hver "Adresse" -modell vil bestå av dens nøkler og respektive verdier. Dette er ikke en dårlig løsning, forutsatt at applikasjonsmodellen din, for eksempel “Brukere”, krever flere adresser. Imidlertid, hvis hver modell bare trenger en adresse (som tilfellet er for de fleste, en postadresse), kan du unødvendig å øke kompleksiteten i applikasjonen ved å legge til flere tabeller og assosiasjoner. Det er ganske enkelt å generere tabeller og assosiasjoner i Rails, som sannsynligvis er årsaken bak dette tredje alternativet. Å opprette en ny "Adresse" -tabell med riktig tilknytning til "Bruker" er så enkelt som: rails g model Adressegata: streng by: strengtilstand: streng zip: strengbruker: referanser Spørsmålet blir da, "er dette best praksis for søknaden din, eller er dette en enkel løsning på et mer sammensatt spørsmål? ”

Løsning:

Rails / PostgreSQL er en vanlig teknologibunke som brukes i utvikling og produksjon. Det er en metode for å lagre adresser i riktig form ved å aktivere utvidelsen ‘hstore’. Denne utvidelsen lar oss lagre data som typen 'hstore' (hash store). Det første trinnet er å aktivere ‘hstore’ -modulen. For å gjøre dette, skriver vi en overføring:

Når vi kjører ‘rails db: migrer’ fra kommandolinjen, vil Postgres aktivere utvidelsen ‘hstore’. Dette kan bekreftes ved å sjekke schema.rb-filen. Nær toppen av filen skal du nå se:

 # Dette er utvidelser som må aktiveres for å støtte denne databasen
enable_extension “plpgsql”
enable_extension “hstore”

Deretter oppretter vi en overføring for brukermodellen:

Legg merke til hvordan vi bruker datatypen ‘hstore’ for adressefeltet. Dette gjør det mulig for oss å lagre nøkkel / verdipar innenfor "adresse".

Bortsett: Feltet 'hstore' kan brukes til å lagre alle nøkkel / verdipar. I denne artikkelen utforsker vi en "Adresse", men den er like nyttig for å lagre "Innstillinger" eller annen hashdatatype.

Så nå har vi et enkelt felt som vi vet kan lagre data i form av, City => "Wonderland" og State => "PA". Vi kan opprette ‘Bruker’-modellen og‘ Brukere ’-kontrolleren, men hvordan lagrer vi egentlig nøkkel / verdipar i et enkelt databasefelt? Det er en annen vurdering å ta, hvordan kan vi vedvare nøkkel- / verdiparet City => "Wonderland" til feltet "address"?

Fra kontrollerens perspektiv må vi først hviteliste noen parametere før de kan tildeles masse. Dette gjøres i den private metoden ‘user_params’, det samme som alle andre databasefelt.

Ved å hvitliste hva som kan tilordnes under adresse, har vi gitt spesifikke instruksjoner om dataene vi forventer. Adressefeltet kan ha et by- / verdipar, eller et stat / verdipar, men ikke et ape / verdipar.

I vårt brukerskjema gir vi de riktige feltene for å samle inn dataene:

Hele skjemaet vises for demonstrasjon. Start og slutt på adressefeltet er imidlertid merket med HTML-kommentarer. Legg merke til hvordan vi bruker skjemahjelperen til å opprette felt for adressen. Hvert felt tilsvarer en hvitelistet parameter vi spesifiserte i kontrolleren. Selv om det ikke er relevant for denne artikkelen, er skjemaet stylet med klasser fra Semantic-UI-biblioteket - noe som betyr at den kommer til å være responsiv og se fantastisk ut!

Over skjema vises i nettleser

Vi kan raskt opprette en bruker og se hvordan "Adresse" -feltet ser ut:

Adressefeltet lagres som en hash av nøkkel / verdipar, perfekt!

På bildet over er uttrykket "emne" synonymt med "bruker". Som du kan se, har "Adresse" -feltet lagret nøkkel- / verdiparene fra kontrolleren akkurat som vi forventet. Hvis vi vil finne verdien av en bestemt brukers by vi kan bruke, @ user.address ['city'], og dette vil returnere "Wonderland" i vårt eksempelbrukssak.

I denne artikkelen oppdaget vi den optimale metoden for å lagre og spørre om komplekse datatyper i PostgreSQL via ‘hstore’ utvidelsen. Vi har bestemt at de beste trinnene i å opprette en webapplikasjon som beste praksis planlegger og samler informasjon. Vi lærte også verdien av å oppdage informasjon selv ved å forske og lese dokumentasjon. Bare fordi en annen utvikler eller selskap gjør noe på en måte, betyr ikke det at vi blindt må følge. Det er viktig å stille spørsmål ved "hvorfor" og bruke våre egne kognitive evner til å logisk trekke konklusjoner. Jeg håper du fant denne artikkelen nyttig. For mer gratis informasjon og veiledninger om webteknologier, besøk Learn2Code.