Mester Laravel Eloquent: Modellrelasjoner enkelt forklart

by
Tweet
Share
Share
Pin
0 Shares

Forholdet mellom modeller i Laravel Eloquent

Modeller og deres innbyrdes forhold utgjør kjernen i Laravel Eloquent. Hvis du opplever vanskeligheter med dette, eller sliter med å finne en lettfattelig og utfyllende veiledning, kan du starte her!

Det er lett for en forfatter å fremstå som ekspert når man sitter på den andre siden av en artikkel om programmering. Men jeg skal være ærlig – jeg strevde mye med å lære Laravel, spesielt siden det var mitt første fullstack-rammeverk. En av årsakene var at jeg ikke brukte det i jobbsammenheng, men utforsket det av ren nysgjerrighet. Jeg prøvde, kom et stykke på vei, ble forvirret, ga opp, og til slutt glemte jeg alt. Dette må jeg ha gjort fem-seks ganger før ting begynte å gi mening (dokumentasjonen var selvsagt ikke til hjelp).

Det som fortsatt var uklart, var Eloquent, eller i det minste forholdet mellom modellene (siden Eloquent er for omfattende til å lære seg fullt ut). Eksemplene med forfattere og blogginnlegg virker latterlige, siden virkelige prosjekter er langt mer komplekse. Likevel bruker den offisielle dokumentasjonen de samme (eller lignende) eksemplene. Selv når jeg fant en nyttig artikkel eller ressurs, var forklaringen så dårlig eller mangelfull at det hele var bortkastet tid.

(Jeg har forresten blitt kritisert for å ha angrepet den offisielle dokumentasjonen tidligere, så hvis du har lignende tanker, er mitt standardsvar: sjekk ut Django-dokumentasjonen og ta kontakt med meg etterpå.)

Etter hvert falt brikkene på plass, og det ga mening. Jeg klarte endelig å modellere prosjekter på en god måte og bruke modellene uten problemer. En dag oppdaget jeg noen smarte samlingstriks som gjør dette arbeidet mer behagelig. I denne artikkelen har jeg tenkt å dekke alt, fra det mest grunnleggende, og deretter gå gjennom alle mulige brukstilfeller du vil møte i virkelige prosjekter.

Hvorfor er modellforhold i Eloquent vanskelige?

Dessverre ser jeg altfor mange Laravel-utviklere som ikke har skikkelig forståelse for modeller.

Men hvorfor er det slik?

Selv i dag, med alle kurs, artikler og videoer om Laravel, er den generelle forståelsen fortsatt mangelfull. Jeg mener dette er et viktig poeng som fortjener litt refleksjon.

Hvis du spør meg, vil jeg si at modellforhold i Eloquent slett ikke er vanskelig. I hvert fall ikke sett fra definisjonen av «vanskelig». Live-skjemaoverføringer er vanskelige. Å skrive en ny malmotor er vanskelig. Å bidra med kode til selve Laravel-kjernen er vanskelig. Sammenlignet med dette er det å lære og bruke en ORM . . . vel, det kan ikke være vanskelig! 🤭🤭

Det som egentlig skjer, er at PHP-utviklere som lærer Laravel, synes Eloquent er vanskelig. Det er det egentlige underliggende problemet, og etter min mening er det flere faktorer som bidrar til dette (advarsel om en upopulær mening!):

  • Før Laravel var de fleste PHP-utvikleres erfaring med rammeverk begrenset til CodeIgniter (som forresten fortsatt eksisterer, selv om det har blitt mer likt Laravel/CakePHP). I det gamle CodeIgniter-fellesskapet (hvis det eksisterte), var «beste praksis» å plassere SQL-spørringer direkte der det var behov for dem. Selv om vi har en ny CodeIgniter i dag, har vanene overtatt. Som et resultat er ideen om en ORM helt ny for mange PHP-utviklere når de begynner med Laravel.
  • Ser man bort fra den svært lille andelen PHP-utviklere som har erfaring med rammeverk som Yii, CakePHP osv., er de resterende vant til å jobbe med ren PHP eller i et miljø som WordPress. Også her eksisterer ikke en OOP-basert tankegang, så et rammeverk, en tjenestecontainer, et designmønster, en ORM . . . dette er fremmede konsepter.
  • Det finnes lite eller ingen tradisjon for kontinuerlig læring i PHP-verdenen. Gjennomsnittsutvikleren er fornøyd med å jobbe med enkle serveroppsett, bruke relasjonsdatabaser og utføre spørringer skrevet som strenger. Asynkron programmering, web-sockets, HTTP 2/3, Linux (glem Docker), enhetstesting, domenedrevet design – alt dette er ukjente ideer for en overveldende andel PHP-utviklere. Dette fører til at det å sette seg inn i noe nytt og utfordrende, helt til man er komfortabel med det, ikke skjer når man møter Eloquent.
  • Den generelle forståelsen av databaser og modellering er også dårlig. Siden databasedesign er direkte og uløselig knyttet til Eloquent-modeller, øker dette vanskelighetsgraden.

Jeg prøver ikke å være kritisk eller generalisere – det finnes mange utmerkede PHP-utviklere, men deres totale andel er svært lav.

Hvis du leser dette, betyr det at du har overvunnet alle disse barrierene, oppdaget Laravel og begynt å jobbe med Eloquent.

Gratulerer! 👏

Du er nesten i mål. Alle byggeklossene er på plass, og vi trenger bare å gå gjennom dem i riktig rekkefølge og med tilstrekkelig detalj. Med andre ord, la oss starte på databasenivå.

Databasemodeller: Relasjoner og kardinalitet

For å gjøre det enkelt antar vi at vi bare jobber med relasjonsdatabaser i denne artikkelen. En årsak er at ORM-er opprinnelig ble utviklet for relasjonsdatabaser, og den andre grunnen er at RDBMS fortsatt er svært populære.

Datamodell

La oss først forstå datamodeller bedre. Ideen om en modell (eller en datamodell, for å være presis) kommer fra databasen. Ingen database, ingen data, og dermed ingen datamodell. Og hva er en datamodell? Kort fortalt er det måten du velger å lagre eller strukturere dataene dine på. I en nettbutikk kan du for eksempel lagre alt i en gigantisk tabell (en FORFERDELIG praksis, men dessverre ikke uvanlig i PHP-verdenen). Det ville være din datamodell. Du kan også dele dataene i 20 hovedtabeller og 16 koblingstabeller, som også vil være en datamodell.

Vær også klar over at måten data er strukturert på i databasen ikke trenger å samsvare 100 % med hvordan de er organisert i rammeverkets ORM. Men man bør alltid bestrebe seg på å holde ting så likt som mulig, slik at vi ikke trenger å forholde oss til enda en ting under utviklingen.

Kardinalitet

La oss også få dette begrepet raskt unna veien: kardinalitet. Det refererer bare til «telling», enkelt sagt. Så 1, 2, 3. . . alt kan være kardinaliteten til noe. Ferdig med det. La oss gå videre!

Forhold

Når vi lagrer data i et hvilket som helst system, finnes det måter datapunkter kan være relatert til hverandre på. Jeg vet at dette høres abstrakt og kjedelig ut, men hold ut litt til. Måtene de ulike dataelementene er koblet sammen på, kalles forhold. La oss først se på noen eksempler som ikke har med databaser å gjøre, slik at vi er sikre på at vi forstår ideen.

  • Hvis vi lagrer alt i en matrise, er en mulig sammenheng: det neste dataelementet har en indeks som er én større enn den forrige.
  • Hvis vi lagrer data i et binært tre, er en mulig sammenheng at det venstre undertreet alltid har mindre verdier enn foreldrenoden (hvis vi velger å vedlikeholde treet på denne måten).
  • Hvis vi lagrer data som en rekke arrays med lik lengde, kan vi etterligne en matrise, og egenskapene til denne blir da forholdene for dataene våre.

Vi ser altså at ordet «forhold», i sammenheng med data, ikke har en fast betydning. Hvis to personer så på de samme dataene, kan de identifisere to svært forskjellige dataforhold (hei, statistikk!), og begge kan være gyldige.

Relasjonsdatabaser

Basert på alle begrepene vi har diskutert til nå, kan vi endelig snakke om noe som har en direkte tilknytning til modeller i et nettrammeverk (Laravel) – relasjonsdatabaser. For de fleste av oss er de mest brukte databasene MySQL, MariaDB, PostgreSQL, MSSQL, SQL Server, SQLite eller lignende. Vi kan også vagt vite at disse kalles RDBMS, men de fleste av oss har glemt hva det faktisk betyr, og hvorfor det er viktig.

«R» i RDBMS står for relasjonell, selvfølgelig. Dette er ikke et vilkårlig valgt begrep. Med dette fremhever vi det faktum at disse databasesystemene er utviklet for å håndtere forhold mellom lagrede data på en effektiv måte. «Relasjon» har her en streng matematisk betydning, og selv om ingen utvikler trenger å bekymre seg for dette, er det nyttig å vite at det finnes et strengt matematisk fundament under denne typen databaser.

Utforsk disse ressursene for å lære SQL og NoSQL.

Vi vet altså fra erfaring at data i RDBMS lagres som tabeller. Men hvor finnes forholdene?

Typer forhold i RDBMS

Dette er kanskje den viktigste delen av hele temaet rundt Laravel og modellforhold. Hvis du ikke forstår dette, vil Eloquent aldri gi mening, så vær oppmerksom de neste minuttene (det er ikke engang så vanskelig).

En RDBMS lar oss ha relasjoner mellom data – på databasenivå. Dette betyr at disse forholdene ikke er upraktiske eller subjektive, men kan skapes eller utledes av ulike personer med samme resultat.

Samtidig finnes det visse muligheter eller verktøy i en RDBMS som lar oss opprette og håndheve disse forholdene, som for eksempel:

  • Primærnøkkel
  • Fremmednøkkel
  • Begrensninger

Jeg vil ikke at denne artikkelen skal bli et kurs i databaser, så jeg antar at du vet hva disse konseptene er. Hvis ikke, eller hvis du føler deg usikker, anbefaler jeg denne informative videoen (utforsk gjerne hele serien):

Disse RDBMS-relasjonene er også de vanligste i virkelige applikasjoner (ikke alltid, siden et sosialt nettverk best modelleres som en graf og ikke som en samling tabeller). La oss se nærmere på dem, en etter en, og forsøke å forstå hvor de kan være nyttige.

En-til-en-forhold

I nesten alle webapplikasjoner finnes det brukerkontoer. Følgende er også sant (generelt sett) om brukere og kontoer:

  • En bruker kan bare ha én konto.
  • En konto kan bare eies av én bruker.

Vi kan selvfølgelig argumentere for at en person kan registrere seg med en annen e-postadresse og opprette to kontoer, men fra webapplikasjonens perspektiv er dette to forskjellige personer med to forskjellige kontoer. Applikasjonen vil for eksempel ikke vise data fra én konto i en annen.

Det dette betyr er at hvis du har en slik situasjon i applikasjonen din, og du bruker en relasjonsdatabase, må du designe den som et en-til-en-forhold. Merk at ingen tvinger deg kunstig – det er en tydelig situasjon i forretningsdomenet, og du bruker en relasjonsdatabase. Det er først når begge disse betingelsene er oppfylt at du har behov for et en-til-en-forhold.

For dette eksemplet (brukere og kontoer) kan vi implementere dette forholdet slik når vi oppretter skjemaet:

CREATE TABLE users(
    id INT NOT NULL AUTO_INCREMENT,
    email VARCHAR(100) NOT NULL,
    password VARCHAR(100) NOT NULL,
    PRIMARY KEY(id)
);

CREATE TABLE accounts(
    id INT NOT NULL AUTO_INCREMENT,
    role VARCHAR(50) NOT NULL,
    PRIMARY KEY(id),
    FOREIGN KEY(id) REFERENCES users(id)
);

La du merke til trikset her? Det er ganske uvanlig når man bygger apper generelt, men i kontotabellen har vi felt-ID-en satt som både primærnøkkel og fremmednøkkel! Fremmednøkkel-egenskapen kobler den til brukertabellen (selvfølgelig 🙄), mens primærnøkkel-egenskapen gjør ID-kolonnen unik – et ekte en-til-en-forhold!

Riktignok er etterlevelsen av dette forholdet ikke garantert. Det er for eksempel ingenting som hindrer meg i å legge til 200 nye brukere uten å legge til én eneste oppføring i kontotabellen. Hvis jeg gjør det, ender jeg opp med et en-til-null-forhold! 🤭🤭 Men innenfor grensene for den rene strukturen er det det beste vi kan gjøre. Hvis vi vil forhindre at brukere legges til uten kontoer, må vi ty til en form for programmeringslogikk, enten i form av databaseutløsere eller valideringer håndhevet av Laravel.

Hvis du begynner å føle deg stresset, har jeg noen gode råd:

  • Ta det med ro. Så rolig du trenger. I stedet for å prøve å fullføre denne artikkelen og de 15 andre som du har lagt til bokmerkene i dag, konsentrer deg om denne. La det ta 3, 4, 5 dager hvis det er det som trengs – målet ditt bør være å krysse av modellforhold i Eloquent for alltid. Du har hoppet fra artikkel til artikkel tidligere, kastet bort hundrevis av timer uten at det har hjulpet. Så gjør noe annerledes denne gangen. 😇
  • Selv om denne artikkelen handler om Laravel Eloquent, kommer det langt senere. Grunnlaget for alt dette er databaseskjemaet, så fokuset vårt bør være å få det riktig først. Hvis du ikke kan arbeide utelukkende på databasenivå (og antar at det ikke finnes rammeverk i verden), vil ikke modeller og forhold gi full mening. Så glem Laravel for nå. Helt. Vi snakker bare om databasedesign foreløpig. Ja, jeg kommer til å komme med referanser til Laravel nå og da, men jobben din er å ignorere dem fullstendig hvis de gjør bildet vanskeligere for deg.
  • Senere kan du lese litt mer om databaser og hva de tilbyr. Indekser, ytelse, triggere, underliggende datastrukturer og deres oppførsel, caching, forhold i MongoDB. . . alle tangentielle emner du kan dekke, vil være til hjelp for deg som ingeniør. Husk at rammemodeller bare er overflater; den virkelige funksjonaliteten til en plattform kommer fra de underliggende databasene.

En-til-mange-forhold

Jeg er usikker på om du har innsett det, men dette er den typen forhold vi intuitivt skaper i vårt daglige arbeid. Når vi oppretter en ordretabell (et hypotetisk eksempel) for å lagre en fremmednøkkel til brukertabellen, oppretter vi et en-til-mange-forhold mellom brukere og ordrer. Hvorfor det? Jo, ser man på det fra perspektivet om hvem som kan ha hvor mange, har én bruker lov til å ha mer enn én ordre, noe som er slik de fleste nettbutikker fungerer. Og fra motsatt side sier forholdet at en ordre bare kan tilhøre én bruker, noe som også gir mye mening.

I datamodellering, RDBMS-bøker og systemdokumentasjon er denne situasjonen representert skjematisk på følgende måte:

Legg merke til de tre linjene som danner en slags gaffel? Dette er symbolet for «mange», og dette diagrammet sier at én bruker kan ha mange ordrer.

Disse «mange» og «en»-tellingene vi stadig møter, er det som kalles kardinaliteten til et forhold (husker du dette ordet fra tidligere?). Igjen, i denne artikkelen har ikke begrepet noen bruksverdi, men det kan være nyttig å vite om det skulle dukke opp i jobbintervjuer eller andre steder.

Enkelt, ikke sant? Og når det gjelder faktisk SQL, er det også enkelt å opprette dette forholdet. Det er faktisk mye enklere enn med et en-til-en-forhold!

CREATE TABLE users(
    id INT NOT NULL AUTO_INCREMENT,
    email VARCHAR(100) NOT NULL,
    password VARCHAR(100) NOT NULL,
    PRIMARY KEY(id)
);

CREATE TABLE orders(
    id INT NOT NULL AUTO_INCREMENT,
    user_id INT NOT NULL,
    description VARCHAR(50) NOT NULL,
    PRIMARY KEY(id),
    FOREIGN KEY(user_id) REFERENCES users(id)
);

Ordretabellen lagrer bruker-ID-er for hver ordre. Siden det ikke finnes en begrensning som sier at bruker-ID-ene i ordretabellen må være unike, kan vi gjenta en enkelt ID mange ganger. Det er dette som skaper en-til-mange-forholdet, og ikke noe mystisk som skjuler seg under overflaten. Bruker-ID-ene lagres på en enkel måte i ordretabellen, og SQL har ingen forståelse av en-til-mange, en-til-en og så videre. Men når vi først lagrer data på denne måten, kan vi se for oss at det er et en-til-mange-forhold.

Forhåpentligvis gir dette mening nå. Eller i det minste mer mening enn før. 😅 Husk at akkurat som med alt annet, handler dette bare om øvelse. Når du har gjort dette 4–5 ganger i virkelige situasjoner, vil du ikke engang tenke over det.

Mange-til-mange-forhold

Den neste typen forhold som oppstår i praksis, er det såkalte mange-til-mange-forholdet. Før vi bekymrer oss for rammeverk eller dykker ned i databaser, la oss tenke på en virkelig analogi: bøker og forfattere. Tenk på favorittforfatteren din. De har skrevet mer enn én bok, ikke sant? Samtidig er det ganske vanlig å se flere forfattere samarbeide om én bok (i hvert fall innen sakprosa). Så én forfatter kan skrive mange bøker, og mange forfattere kan skrive én bok. Mellom de to enhetene (bok og forfatter) danner dette et mange-til-mange-forhold.

Siden det er svært usannsynlig at du skal lage en app som involverer biblioteker eller bøker og forfattere, la oss se på noen flere eksempler. I en B2B-setting bestiller en produsent varer fra en leverandør og mottar en faktura. Fakturaen vil inneholde flere poster, der hver enkelt post viser antallet og varen som er levert, for eksempel 5-tommers rørstykker x 200 osv. I denne situasjonen har varer og fakturaer et mange-til-mange-forhold (tenk deg om og overbevis deg selv). I et flåtestyringssystem vil kjøretøy og sjåfører ha et lignende forhold. På en e-handelsside kan brukere og produkter ha et mange-til-mange-forhold hvis vi vurderer funksjoner som favoritter eller ønskelister.

Hvordan oppretter vi dette mange-til-mange-forholdet i SQL? Basert på kunnskapen vår om hvordan et en-til-mange-forhold fungerer, kan det være fristende å tro at vi bør lagre fremmednøkler til den andre tabellen i begge tabellene. Dette vil imidlertid skape store problemer. Se på dette eksemplet der bøker og forfattere skal ha et mange-til-mange-forhold:

Ved første øyekast ser alt greit ut – bøker er kartlagt til forfattere nøyaktig på en mange-til-mange-måte. Men se nøye på dataene i forfattertabellen: Bok-ID 12 og 13 er begge skrevet av Peter M. (forfatter-ID 2). Dette medfører at vi må gjenta oppføringene. Ikke bare har forfattertabellen nå problemer med dataintegritet (egentlig normalisering og alt det), men verdiene i ID-kolonnen gjentas nå. Dette betyr at i det designet vi har valgt, kan det ikke være noen primærnøkkelkolonne (siden primærnøkler ikke kan ha dupliserte verdier), og alt faller sammen.

Det er klart at vi trenger en annen måte å gjøre dette på, og heldigvis er dette problemet allerede løst. Siden det å lagre fremmednøkler direkte i begge tabellene skaper problemer, er den riktige måten å opprette mange-til-mange-forhold i RDBMS å lage en såkalt «koblingstabell». Tanken er i utgangspunktet å la de to opprinnelige tabellene være uforstyrret og lage en tredje tabell for å demonstrere mange-til-mange-kartleggingen.

La oss gjøre om det mislykkede eksemplet til å inkludere en koblingstabell:

Legg merke til at det har skjedd store endringer:

  • Antall kolonner i forfattertabellen er redusert.
  • Antall kolonner i boktabellen er redusert.
  • Antall rader i forfattertabellen er redusert, ettersom det ikke lenger er behov for gjentakelser.
  • En ny tabell, kalt forfattere_bøker, har dukket opp. Den inneholder informasjon om hvilken forfatter-ID som er koblet til hvilken bok-ID. Vi kunne ha kalt koblingstabellen hva som helst, men konvensjonen er å slå sammen de to tabellene den representerer, med en understrek.

Koblingstabellen har ingen primærnøkkel og inneholder i de fleste tilfeller bare to kolonner – ID-er fra de to tabellene. Det er nesten som om vi fjernet fremmednøkkelkolonnene fra det tidligere eksemplet og limte dem inn i denne nye tabellen. Siden det ikke er noen primærnøkkel, kan det være så mange gjentakelser som nødvendig for å registrere alle forholdene.

Vi ser nå at koblingstabellen viser forholdene tydelig, men hvordan får vi tilgang til dem i applikasjonene våre? Hemmeligheten ligger i navnet – koblingstabell. Dette er ikke et kurs i SQL-spørringer, så jeg går ikke i dybden på det. Men ideen er at hvis du vil ha alle bøkene til en bestemt forfatter i én effektiv spørring, kan du SQL-sammenføye tabellene i samme rekkefølge – forfattere, forfattere_bøker og bøker. Forfattere- og forfattere_bøker-tabellene er sammenføyd over henholdsvis ID- og forfatter_ID-kolonnene, mens tabellene forfattere_bøker og bøker er sammenføyd på henholdsvis bok_ID- og ID-kolonnene.

Utmattende, ja. Men se det fra den lyse siden – vi har fullført all den nødvendige teorien eller grunnarbeidet vi trengte før vi begynner med Eloquent-modeller. Husk at alt dette ikke er valgfritt! Hvis du ikke har kunnskap om databasedesign, vil du være evig forvirret i Eloquent. Uansett hva Eloquent gjør, gjenspeiler detaljene på databasenivå seg perfekt. Dermed er det lett å se hvorfor forsøket på å lære Eloquent mens man unngår RDBMS, er nytteløst.

Opprette modellforhold i Laravel Eloquent

Etter en omvei på ca. 112 000 km, har vi endelig kommet til det punktet der vi kan snakke om Eloquent, modellene, og hvordan man lager og bruker dem. Vi lærte i forrige del av artikkelen at alt begynner med databasen, og hvordan du modellerer dataene dine. Dette fikk meg til å innse at jeg bør bruke et enkelt, komplett eksempel der jeg starter et nytt prosjekt. Samtidig vil jeg at dette eksemplet skal være basert på den virkelige verden, og ikke på blogger og forfattere eller bøker og hyller (som også er en del av den virkelige verden, men som er brukt til det kjedsommelige).

La oss se for oss en butikk som selger kosedyr. La oss også anta at vi har fått kravdokumentet, der vi kan identifisere disse fire enhetene i systemet: brukere, bestillinger, fakturaer, varer, kategorier, underkategorier og transaksjoner. Ja, det er sannsynligvis flere komplikasjoner, men la oss legge det til side og fokusere på overgangen fra et dokument til en app.

Når hovedenhetene i systemet er identifisert, må vi tenke på hvordan de forholder seg til hverandre, i form av databaserelasjonene vi har diskutert. Her er de jeg kan tenke meg:

  • Brukere og bestillinger: En til mange.
  • Bestillinger og fakturaer: En til en. Jeg innser at dette ikke er en absolutt sannhet, og avhengig av forretningsdomenet kan det være et en-til-mange-, et mange-til-en- eller et mange-til-mange-forhold. Men når det gjelder en gjennomsnittlig, liten nettbutikk, vil én ordre bare føre til én faktura, og omvendt.
  • Bestillinger og varer: Mange til mange.
  • Varer og kategorier: Mange til en. Igjen, dette er ikke tilfellet for store e-handelssider, men vi har en liten operasjon.
  • Kategorier og underkategorier: En til mange. Igjen, du vil finne mange eksempler fra den virkelige verden som motsier dette, men Eloquent er vanskelig nok som det er, så la oss ikke komplisere datamodelleringen!
  • Bestillinger og transaksjoner: En til mange. Jeg vil også legge til disse to punktene som begrunnelse for valget mitt: 1) Vi kunne også lagt til et forhold mellom transaksjoner og fakturaer. Det er bare en beslutning om datamodellering. 2) Hvorfor en til mange her? Vel, det er vanlig at en ordrebetaling mislykkes av en eller annen grunn, og så lykkes den neste gang. I dette tilfellet har vi to transaksjoner som er opprettet for den bestillingen. Om vi ønsker å vise disse mislykkede transaksjonene, er en forretningsavgjørelse, men det er alltid en god idé å fange opp verdifulle data.

Finnes det andre forhold? Ja, mange flere forhold er mulige, men de er ikke praktiske. For eksempel kan vi si at en bruker har mange transaksjoner, slik at det bør være et forhold mellom dem. Det man må innse her, er at det allerede finnes et indirekte forhold: brukere → bestillinger → transaksjoner. Generelt er dette tilstrekkelig, siden RDBMS er eksperter på å sammenføye tabeller. For det andre vil det å opprette denne relasjonen kreve at vi legger til en user_id-kolonne i transaksjonstabellen. Hvis vi gjorde dette for alle mulige direkte relasjoner, ville vi lagt mye mer press på databasen (i form av mer lagring, spesielt hvis UUID-er brukes, og vedlikehold av indekser). Dette ville saknet systemet som helhet. Hvis virksomheten sier at de trenger transaksjonsdata og må ha dem i løpet av 1,5 sekunder, kan vi bestemme oss for å legge til forholdet for å øke hastigheten (avveininger, avveininger…).

Og nå, mine damer og herrer, er det på tide å skrive selve