Sådan tilføjer du en database til din app (uden at miste data senere)

For at tilføje en database til din app skal du vælge en administreret relationel database (Postgres er den typiske standard), gemme dens forbindelsesstreng som en hemmelighed på serveren, oprette én tabel for hver type ting din app gemmer, og lade din backend — aldrig browseren — læse og skrive til den. Hvis du bygger med et AI-værktøj til apps, kan du som regel bare skrive „gem dette i en database“, og agenten opsætter tabellerne og koden; din opgave er at beskrive dataene tydeligt og kontrollere, at de faktisk bliver gemt.

Denne guide dækker hvornår du har brug for en database, de vigtigste muligheder, hvordan du beskriver dine data, og de fejl der fører til tabte eller lækkede data.

Hvornår din app har brug for en database

Du har brug for en database, når din app skal huske noget, efter siden er lukket, eller dele data mellem personer. Typiske tegn:

• Besøgende indsender noget: en formular, en tilmelding, en booking eller en ordre
• Brugere har konti med deres eget gemte indhold
• En administrator skal kunne se eller redigere det, andre har oprettet
• Du vil have rapporter eller optællinger over tid

Du har ikke brug for en database til et statisk site, hvor alle ser det samme indhold, som en portefølje eller en simpel landingsside. Hvis du er usikker på, hvad en database egentlig er, så læs først hvad er en database.

Dine muligheder

Til de fleste små og mellemstore webapps er en relationel database som Postgres det rigtige valg som standard. Den er god til relationer (en kunde har mange ordrer), holder data konsistente, og lader dig stille spørgsmål senere med SQL. Se hvad er Postgres for en forklaring i almindeligt sprog.

Beskriv dine data før du bygger

Det nyttigste du kan gøre, er at skrive ned de ting din app gemmer, og hvordan de hænger sammen. Du behøver ikke databasejargon. For en bookingapp:

• Kunder: navn, e-mail, telefon
• Ydelser: navn, varighed, pris
• Bookinger: hvilken kunde, hvilken ydelse, starttidspunkt, status (afventer, bekræftet, annulleret)

Det er tre tabeller. „Hvilken kunde“ og „hvilken ydelse“ bliver til forbindelser (fremmednøgler) mellem dem. At få det rigtigt tidligt betyder langt mere end noget teknologivalg, fordi det er sværere at ændre formen på data, der allerede har rigtige rækker, end at ændre et sidelayout.

Nogle tommelfingerregler:

• Én tabel for hver type ting. Pak ikke ordrer ind i en tekstkolonne på kunden.
• Giv hver række et ID og et oprettelsestidspunkt. Du får brug for begge dele senere.
• Brug de rigtige typer. Datoer som datoer, beløb som hele øre eller et decimaltal, ikke som tekst.
• Markér obligatoriske felter som obligatoriske. Lad databasen afvise dårlige data, ikke kun formularen.

Eksempler på prompts

Start med én funktion ad gangen i stedet for at smide et helt skema ind på én gang:

Tilføj en database til denne app. Opret en bookings-tabel med kundens navn, e-mail, ydelse, starttidspunkt og status (afventer, bekræftet, annulleret; standard afventer). Gem indsendelser fra bookingformularen i den, vis en bekræftelsesbesked, og tilføj en administratorside, der lister bookinger med de nyeste først.

Udvid den derefter:

Tilføj en ydelses-tabel (navn, varighed i minutter, pris i øre). Erstat det fritekstfelt for ydelse på bookinger med et link til ydelser, og migrér eksisterende bookinger uden at slette dem.

Og stram den op:

Sørg for, at alle læse- og skrivehandlinger mod databasen sker på serveren. Browseren må aldrig modtage databasens forbindelsesstreng. Valider e-mailen og starttidspunktet på serveren, før der indsættes noget.

Trin for trin

1. Lav en liste over dine data som ovenfor: ting, felter, forbindelser mellem dem.
2. Opret databasen. I et AI-værktøj beder du om det i chatten. Andre steder opretter du en administreret Postgres-instans og kopierer dens forbindelsesstreng.
3. Gem forbindelsesstrengen som en hemmelighed (en miljøvariabel på serveren), aldrig i koden. Se miljøvariabler og hemmeligheder.
4. Opret tabellerne. Brug migreringer — versionerede scripts, der ændrer skemaet — så ændringer kan gentages og rulles tilbage.
5. Byg serverruterne, der opretter, læser, opdaterer og sletter rækker (CRUD). Browseren kalder disse ruter; den taler aldrig direkte med databasen.
6. Forbind brugerfladen til ruterne: formularer der gemmer, lister der indlæses, tomme tilstande når der endnu intet er.
7. Test at data bliver gemt. Indsend noget, genindlæs siden, åbn den i en anden browser. Hvis data ikke er der, blev de ikke gemt i databasen.
8. Kontrollér adgang. Log ind som en anden bruger og bekræft, at du ikke kan se eller redigere den første brugers data.
9. Publicér, og test igen på den live URL, da den publicerede app kan bruge en anden forbindelse end din preview.

Almindelige fejl

• At gemme i browseren og tro, at det er gemt. localStorage virker, indtil nogen åbner appen på en anden enhed. Test altid i en anden browser.
• At lægge forbindelsesstrengen i frontend-koden. Alle kan læse frontend-kode. Det giver dem hele din database.
• Ingen adgangskontrol. „Vis mine ordrer“ skal filtrere efter den indloggede bruger på serveren, ikke i brugerfladen. Det er det hyppigste sikkerhedshul i AI-byggede apps; vores sikkerhedstjekliste dækker det.
• Destruktive skemaændringer. Hvis du beder om at „omdøbe tabellen“ eller „ændre strukturen“, kan den blive droppet og oprettet igen. Når der findes rigtige data, så skriv „migrér de eksisterende rækker, slet intet“.
• At gemme filer i databasen. Billeder og PDF'er hører hjemme i fillagring, med kun deres URL eller nøgle i en tabel. Se sådan tilføjer du filupload.
• Ingen backup. Ved hvordan din platform tager backup, og hvordan du gendanner, før du har kunder.

Tjekliste

• Hver type ting har sin egen tabel med et ID og et oprettelsestidspunkt
• Obligatoriske felter og typer håndhæves af databasen
• Forbindelsesstrengen findes kun i hemmeligheder på serveren
• Alle læse- og skrivehandlinger går gennem serverruter
• Hver bruger kan kun læse og ændre sine egne rækker
• Data overlever en genindlæsning og vises i en anden browser
• Skemaændringer bruger migreringer og bevarer eksisterende rækker
• Du ved hvordan backup og gendannelse fungerer
• Den live app er testet efter publicering

Tilføj en database i Mythex

På Mythex kan hvert projekt få sin egen dedikerede Postgres-database, både på Free og Pro. Du skal normalt ikke klikke på en separat „tilslut“-knap: bed om det i chatten („gem tilmeldinger til venteliste i en database“) eller skriv /database, og forbindelsesoplysningerne indsættes i arbejdsområdet og din publicerede app. Projektindstillingerne viser, om en database er aktiv.

Databasen går i dvale efter 5 minutters inaktivitet og vågner ved næste forespørgsel. Forbruget i den publicerede app faktureres for den tid, den rent faktisk var vågen, fra den samme kreditsaldo som du bruger til at bygge. Hvis du tilføjer en database, efter du har publiceret, skal du publicere igen, så den live app får den med.

Se Database og opskriften Byg en CRUD-app i dokumentationen. For login-delen af data pr. bruger, læs sådan tilføjer du login til din app.

Spørgsmål