Slik legger du til en database i appen din (uten å miste data senere)

For å legge til en database i appen din velger du en administrert relasjonsdatabase (Postgres er vanligvis standarden), lagrer tilkoblingsstrengen i en hemmelighet på serversiden, lager én tabell per type ting appen lagrer, og lar backenden – aldri nettleseren – lese og skrive til den. Hvis du bygger med et AI-verktøy, kan du som regel bare si «lagre dette i en database», og agenten setter opp tabellene og koden. Din jobb er å beskrive dataene tydelig og kontrollere at de faktisk lagres.

Denne guiden dekker når du trenger en database, de viktigste alternativene, hvordan du beskriver dataene dine, og feilene som fører til tapte eller lekkede data.

Når appen din trenger en database

Du trenger en database når appen må huske noe etter at siden er lukket, eller dele data mellom folk. Typiske tegn:

• Besøkende sender inn noe: et skjema, en registrering, en booking eller en bestilling
• Brukere har kontoer med eget lagret innhold
• En administrator må se eller redigere det andre har laget
• Du vil ha rapporter eller tall over tid

Du trenger ikke en for en statisk side der alle ser det samme innholdet, for eksempel en porteføljeside eller en enkel landingsside. Er du usikker på hva en database faktisk er, les hva er en database først.

Dine alternativer

For de fleste små og mellomstore webapper er en relasjonsdatabase som Postgres riktig standard. Den er god på relasjoner (en kunde har mange bestillinger), holder dataene konsistente, og lar deg svare på spørsmål senere med SQL. Se hva er Postgres for en forklaring i vanlig språk.

Beskriv dataene dine før du bygger

Det mest nyttige du kan gjøre er å skrive ned tingene appen din lagrer og hvordan de henger sammen. Du trenger ingen databasejargong. For en bookingapp:

• Kunder: navn, e-post, telefon
• Tjenester: navn, varighet, pris
• Bookinger: hvilken kunde, hvilken tjeneste, starttid, status (venter, bekreftet, avlyst)

Det er tre tabeller. «Hvilken kunde» og «hvilken tjeneste» blir lenker (fremmednøkler) mellom dem. Å få dette riktig tidlig betyr langt mer enn noe teknologivalg, fordi det er vanskeligere å endre formen på data som allerede har ekte rader, enn å endre et sideoppsett.

Noen tommelfingerregler:

• Én tabell per type ting. Ikke pakk bestillinger inn i en tekstkolonne på kunden.
• Gi hver rad en ID og et opprettet-tidspunkt. Du vil trenge begge deler senere.
• Bruk riktige datatyper. Datoer som datoer, penger som hele øre eller desimaltall, ikke som tekst.
• Merk påkrevde felt som påkrevde. La databasen avvise dårlige data, ikke bare skjemaet.

Eksempelprompter

Start med én funksjon om gangen i stedet for å dumpe et helt skjema:

Legg til en database i denne appen. Lag en bookings-tabell med kundenavn, e-post, tjeneste, starttid og status (venter, bekreftet, avlyst; standard venter). Lagre innsendinger fra bookingskjemaet der, vis en suksessmelding, og legg til en administrasjonsside som lister bookinger, nyeste først.

Utvid den deretter:

Legg til en tjeneste-tabell (navn, varighet i minutter, pris i øre). Erstatt det frie tekstfeltet for tjeneste på bookinger med en lenke til tjenester, og migrer eksisterende bookinger uten å slette dem.

Og stram den inn:

Sørg for at alle database-leser og -skrivinger skjer på serveren. Nettleseren må aldri få tilkoblingsstrengen. Valider e-post og starttid på serveren før innsetting.

Steg for steg

1. List opp dataene dine som over: ting, felt, og koblinger mellom dem.
2. Opprett databasen. I et AI-verktøy ber du om den i chatten. Ellers oppretter du en administrert Postgres-instans og kopierer tilkoblingsstrengen.
3. Lagre tilkoblingsstrengen som en hemmelighet (en miljøvariabel på serveren), aldri i koden. Se miljøvariabler og hemmeligheter.
4. Lag tabellene. Bruk migreringer – versjonerte skript som endrer skjemaet – slik at endringer kan gjentas og reverseres.
5. Bygg serverrutene som oppretter, leser, oppdaterer og sletter rader (CRUD). Nettleseren kaller disse rutene; den snakker aldri direkte med databasen.
6. Koble brukergrensesnittet til rutene: skjemaer som lagrer, lister som lastes, tomme tilstander når det ikke finnes noe ennå.
7. Test at dataene består. Send inn noe, last siden på nytt, og åpne den i en annen nettleser. Hvis dataene ikke er der, ble de ikke lagret i databasen.
8. Sjekk tilgang. Logg inn som en annen bruker og bekreft at du ikke kan se eller redigere den første brukerens data.
9. Publiser, og test på nytt på den live adressen, siden den publiserte appen kan bruke en annen tilkobling enn forhåndsvisningen.

Vanlige feil

• Å lagre i nettleseren og tro at det er lagret. localStorage ser ut til å fungere helt til noen åpner appen på en annen enhet. Test alltid i en andre nettleser.
• Tilkoblingsstrengen i frontend-koden. Alle kan lese frontend-kode. Det gir dem hele databasen din.
• Ingen tilgangskontroll. «Vis mine bestillinger» må filtrere på den innloggede brukeren på serveren, ikke i grensesnittet. Dette er det vanligste sikkerhetshullet i AI-bygde apper; vår sikkerhetssjekkliste for AI-bygde apper dekker det.
• Destruktive skjemaendringer. Hvis du ber om å «gi tabellen nytt navn» eller «endre strukturen», kan den bli droppet og laget på nytt. Når det finnes ekte data, skriv «migrer de eksisterende radene, ikke slett noe».
• Å lagre filer i databasen. Bilder og PDF-er hører hjemme i fillagring, med bare URL-en eller nøkkelen i en tabell. Se hvordan legge til filopplastinger.
• Ingen sikkerhetskopier. Vit hvordan plattformen din tar sikkerhetskopi og hvordan du gjenoppretter, før du har kunder.

Sjekkliste

• Hver type ting har sin egen tabell med ID og opprettet-tidspunkt
• Påkrevde felt og typer håndheves av databasen
• Tilkoblingsstrengen ligger bare i hemmeligheter på serversiden
• Alle leser og skriver går gjennom serverruter
• Hver bruker kan bare lese og endre sine egne rader
• Dataene overlever en omlasting og vises i en annen nettleser
• Skjemaendringer bruker migreringer og beholder eksisterende rader
• Du vet hvordan sikkerhetskopiering og gjenoppretting fungerer
• Den live appen er testet etter publisering

Legge til en database i Mythex

I Mythex kan hvert prosjekt få sin egen dedikerte Postgres-database, både på Free og Pro. Du trenger vanligvis ikke en egen «koble til»-knapp: be om det i chatten («lagre venteliste-e-poster i en database») eller skriv /database, så settes tilkoblingsdetaljene inn i arbeidsområdet og i den publiserte appen din. Prosjektinnstillingene viser om en database er aktiv.

Databasen sover etter 5 minutter uten aktivitet og våkner ved neste forespørsel. Publisert bruk belastes for den tiden den faktisk var våken, fra samme kredittsaldo som du bruker til bygging. Hvis du legger til en database etter at du har publisert, må du publisere på nytt, slik at den live appen tar den i bruk.

Se Database og oppskriften Bygg en CRUD-app i dokumentasjonen. For innloggingsdelen av data per bruker, les hvordan legge til innlogging i appen din.

Spørsmål