Hvad er en database? En guide for folk, der bygger apps

En database er en struktureret samling af information, som en app gemmer i og læser fra: dens brugere, ordrer, bookinger, beskeder. I modsætning til information, der kun ligger i en browserfane, er data i en database stadig der efter en genindlæsning eller en genstart, og alle, der bruger appen, ser de samme poster. De fleste databaser organiserer data i tabeller, lidt ligesom ark i et regneark, men med strenge regler, der holder data konsistente.

Hvorfor det betyder noget, når du bygger med AI

Den mest almindelige overraskelse for folk, der bygger med AI, er en app, der ser færdig ud, men glemmer alt. Du tilføjer en kunde, genindlæser siden, og den er væk. Det betyder typisk, at appen gemte data i browserens hukommelse og ikke i en database.

En database er også det sted, hvor mange af dine vigtigste beslutninger ligger, uanset om du er klar over det eller ej:

• Hvad du registrerer. Hvis du ikke gemmer en bookings status, kan du ikke vise, hvilke bookinger der blev aflyst.
• Hvordan ting hænger sammen. Om én kunde kan have mange bookinger, eller én booking mange ydelser, former hele appen.
• Hvem der må se hvad. De fleste privatlivsfejl handler om, hvilke poster en bruger må læse.

Du behøver ikke selv designe databasen. Men en forståelse af det grundlæggende gør det lettere at beskrive dine data klart og opdage problemer tidligt.

En hverdagsanalogi

Forestil dig et velordnet arkivskab på et lille kontor.

Hver skuffe rummer én slags ting: én til kunder, én til aftaler, én til fakturaer. Inde i hver skuffe følger alle mapper det samme format, med de samme felter udfyldt. Hver mappe har et unikt referencenummer, og når en faktura hører til en kunde, noterer fakturamappen kundens nummer i stedet for at kopiere hele kundens sag.

Sådan er en relationel database. Skufferne er tabeller, mapperne er rækker, felterne er kolonner, referencenumrene er primærnøgler, og noterne, der peger på en anden mappe, er fremmednøgler. En god kontorchef håndhæver også regler (ingen aftale uden dato, ingen to kunder med samme nummer), ligesom en database gør.

Et konkret eksempel: en bookingapp for en frisør

Sig at du beder en AI om at bygge et bookingsite til en frisørsalon. En fornuftig database ville have fire tabeller.

services

staff

customers

bookings

Kig på bookings-tabellen. Den kopierer ikke Lenas navn og telefonnummer ind i hver booking; den gemmer customer_id = 101. Hvis Lena ændrer sit telefonnummer, ændres det ét sted, og hver booking viser det nye. Det er kernen i en relationel database: gem hvert faktum én gang, og peg på det.

Den samme struktur kan besvare nyttige spørgsmål:

• "Hvilke tider er ledige for Omar fredag?" Se på Omars bookinger den dag.
• "Hvor meget gav farvebehandlinger i denne måned?" Forbind bookinger med ydelser og læg priserne sammen.
• "Hvilke kunder har ikke booket inden for 90 dage?" Sammenlign kunder med deres seneste booking.

Vigtige begreber

Typer af databaser

Til næsten alt, en iværksætter eller lille virksomhed bygger først, er en relationel database det sikre valg.

Hvor databasen sidder i din app

Besøgende taler aldrig direkte med databasen. Siden i deres browser (frontend) beder din server (backenden) om data, typisk gennem en API. Serveren tjekker, hvem der spørger, og om de må, forespørger derefter databasen og sender kun det tilbage, som den person må se.

Det mellemled er vigtigt. Hvis browseren kunne forespørge databasen direkte med fuld adgang, kunne hvem som helst åbne udviklerværktøjerne og læse alt.

Almindelige fejl og misforståelser

• At gemme data kun i browseren. Browserlager (som localStorage) lever på én enhed og i én browser. Det er fint til et husket filter, ikke til ordrer.
• At proppe alt i én tabel. En enkelt "bookings"-tabel med kundens navn, telefon og ydelsespris kopieret ind i hver række kommer hurtigt ud af sync.
• At gemme adgangskoder som almindelig tekst. Adgangskoder skal hashes, aldrig gemmes læsbart. Se hvad godkendelse er.
• Ingen regler for data. Uden påkrævede felter og unikhedsregler får du bookinger uden dato og dubletter af kunder.
• At glemme sletning. Beslut, om det at slette en kunde også sletter deres bookinger, beholder dem eller blokeres.
• At bruge produktionsdata til at eksperimentere. Test risikable ændringer et sikkert sted først, og hold backups.
• At behandle regnearket som databasen for evigt. Regneark er gode til at starte med, men de har svært ved mange samtidige brugere og rettigheder. Se sådan gør du et regneark til en app.

Hvad du kan bede din AI-builder om

• "Gem dette i en database, ikke i browseren. Fortæl mig, hvilke tabeller du opretter."
• "Vis skemaet som en simpel tabel: hver tabel, dens kolonner, og hvordan de hænger sammen."
• "En kunde kan have mange bookinger; hver booking har præcis én ydelse og én medarbejder."
• "Gør e-mail påkrævet og unik for kunder."
• "Forhindr, at to bookinger for den samme medarbejder overlapper."
• "Kun den indloggede ejer må læse alle bookinger; kunder må kun se deres egne. Håndhæv det på serveren."
• "Når jeg sletter en ydelse, må du ikke slette tidligere bookinger; markér i stedet ydelsen som inaktiv."

Databaser i Mythex

Når din app skal gemme data, tilføjer Mythex en dedikeret Postgres-database til projektet. Du kan bede om det i chatten ("gem tilmeldinger til ventelisten i en database") eller bruge kommandoen /database. Forbindelsesoplysninger sendes automatisk til din app, og agenten opretter tabellerne. Databasen går i dvale efter fem minutters inaktivitet og vågner ved næste forespørgsel, og publiceret brug opkræves for den tid, den var vågen, fra den samme kreditsaldo som bygning. Den er tilgængelig på Free og Pro. Database-dokumentationen dækker detaljerne, og app-skabelonerne indeholder datadrevne udgangspunkter.

Spørgsmål