Hva er en database? En guide for folk som bygger apper

En database er en organisert lagring av informasjon som en app lagrer til og leser fra: brukerne, bestillingene, bookingene og meldingene. I motsetning til informasjon som bare ligger i en nettleserfane, er data i en database der etter en oppdatering eller omstart, og alle som bruker appen ser de samme postene. De fleste databaser organiserer data i tabeller, omtrent som ark i et regneark, men med strenge regler som holder dataene konsistente.

Hvorfor det betyr noe når du bygger med AI

Den vanligste overraskelsen for folk som bygger med AI, er en app som ser ferdig ut, men glemmer alt. Du legger til en kunde, oppdaterer siden, og den er borte. Det betyr vanligvis at appen lagret data i nettleserens minne, ikke i en database.

En database er også der mange av de viktigste beslutningene dine ligger, enten du innser det eller ikke:

• Hva du registrerer. Hvis du ikke lagrer statusen til en booking, kan du ikke vise hvilke bookinger som ble avlyst.
• Hvordan ting henger sammen. Om én kunde kan ha mange bookinger, eller én booking mange tjenester, former hele appen.
• Hvem som kan se hva. De fleste personvernfeil handler om hvilke poster en bruker kan lese.

Du trenger ikke å designe databasen selv. Men å forstå grunnprinsippene lar deg beskrive dataene dine tydelig og oppdage problemer tidlig.

En hverdagslig sammenligning

Tenk deg et velordnet arkivskap på et lite kontor.

Hver skuff holder én type ting: én skuff for klienter, én for avtaler, én for fakturaer. Inne i hver skuff følger hver mappe samme format, med de samme feltene fylt ut. Hver mappe har et unikt referansenummer, og når en faktura tilhører en klient, noterer fakturamappen klientens nummer i stedet for å kopiere hele filen hans.

Slik fungerer en relasjonsdatabase. Skuffene er tabeller, mappene er rader, feltene er kolonner, referansenumrene er primærnøkler, og notatene som peker til en annen mappe er fremmednøkler. En god kontorsjef håndhever også regler, ingen avtale uten dato, to klienter kan ikke ha samme nummer, akkurat som en database gjør.

Et konkret eksempel: en bookingapp for frisørsalong

Anta at du ber en AI om å bygge et bookingnettsted for en frisørsalong. En fornuftig database ville ha fire tabeller.

tjenester

ansatte

kunder

bookinger

Se på tabellen bookinger. Den kopierer ikke Lenas navn og telefonnummer inn i hver booking. Den lagrer kunde_id = 101. Hvis Lena endrer telefonnummeret sitt, endres det ett sted, og hver booking viser det nye. Dette er kjerneideen i en relasjonsdatabase: lagre hvert faktum én gang, og lenk til det.

Samme struktur svarer på nyttige spørsmål:

• «Hvilke tider er ledige for Omar på fredag?» Se på Omars bookinger den dagen.
• «Hvor mye tjente fargebehandlinger denne måneden?» Koble bookingene til tjenestene og legg sammen prisene.
• «Hvilke kunder har ikke booket på 90 dager?» Sammenlign kundene med deres siste booking.

Vanlige begreper forklart

Typer databaser

For nesten alt en gründer eller et lite firma bygger først, er en relasjonsdatabase det trygge standardvalget.

Hvor databasen ligger i appen din

Besøkende snakker aldri direkte med databasen. Siden i nettleseren deres (the frontend) ber serveren din (backend) om data, vanligvis gjennom et API. Serveren sjekker hvem som spør og om de har lov, spør deretter databasen og sender tilbake bare det den personen skal se.

Det mellomsteget er viktig. Hvis nettleseren kunne spørre databasen direkte med full tilgang, kunne hvem som helst åpne utviklerverktøyene og lese alt.

Vanlige feil og misforståelser

• Å beholde data bare i nettleseren. Nettleserlagring (som localStorage) ligger på én enhet og i én nettleser. Det er greit for et husket filter, men ikke for bestillinger.
• Å proppe alt i én tabell. En enkelt tabell «bookinger» der kundens navn, telefon og tjenestepris kopieres inn i hver rad, kommer raskt ut av synk.
• Å lagre passord som klartekst. Passord skal hashes, aldri lagres lesbare. Se hva autentisering er.
• Ingen regler for dataene. Uten påkrevde felt og unikhetsregler får du bookinger uten dato og dupliserte kunder.
• Å glemme sletting. Bestem om sletting av en kunde også sletter bookingene deres, beholder dem, eller blokkeres.
• Å bruke produksjonsdata til eksperimenter. Test risikable endringer et trygt sted først, og behold sikkerhetskopier.
• Å behandle regnearket som databasen for alltid. Regneark er flotte for å starte med, men de sliter med mange brukere samtidig og tillatelser. Se hvordan gjøre et regneark om til en app.

Hva du bør be AI-byggeren din om

• «Lagre dette i en database, ikke i nettleseren. Fortell meg hvilke tabeller du vil lage.»
• «Vis meg skjemaet som en enkel tabell: hver tabell, kolonnene og hvordan de henger sammen.»
• «En kunde kan ha mange bookinger. Hver booking har nøyaktig én tjeneste og én ansatt.»
• «Gjør e-post påkrevd og unik for kunder.»
• «Stopp at to bookinger for samme ansatte overlapper.»
• «Bare den innloggede eieren kan lese alle bookinger. Kunder kan bare se sine egne. Håndhev dette på serveren.»
• «Når jeg sletter en tjeneste, må du ikke slette tidligere bookinger. Marker tjenesten som inaktiv i stedet.»

Databaser i Mythex

Når appen din trenger å lagre data, legger Mythex til en egen Postgres-database i prosjektet. Du kan be om det i chatten («lagre venteliste-registreringer i en database») eller bruke kommandoen /database. Tilkoblingsdetaljene sendes automatisk til appen din, og agenten oppretter tabellene. Databasen sover etter fem minutter uten aktivitet og våkner ved neste forespørsel. For publiserte apper belastes bruk for tiden den var våken, fra samme kreditsaldo som bygging. Den er tilgjengelig på Free og Pro. Dokumentasjonen for databasen forklarer detaljene, og app-malene inkluderer datadrevne utgangspunkter.

Spørsmål