Så lägger du till en databas i din app (utan att förlora data senare)

För att lägga till en databas i din app väljer du en hanterad relationsdatabas (Postgres är det vanliga standardvalet), håller dess anslutningssträng i en hemlighet på servern, skapar en tabell per typ av sak din app lagrar och låter din backend — aldrig webbläsaren — läsa och skriva till den. Om du bygger med en AI-appbyggare kan du oftast bara säga “spara detta i en databas” så sätter agenten upp tabellerna och koden; din uppgift är att beskriva datan tydligt och kontrollera att den faktiskt sparas.

Den här guiden tar upp när du behöver en databas, de vanligaste alternativen, hur du beskriver din data och de misstag som orsakar förlorad eller läckt data.

När din app behöver en databas

Du behöver en databas när din app måste komma ihåg något efter att sidan stängts, eller dela data mellan personer. Typiska tecken:

• Besökare skickar in något: ett formulär, en registrering, en bokning, en order
• Användare har konton med eget sparat innehåll
• En admin behöver se eller redigera det andra skapat
• Du vill ha rapporter eller räkningar över tid

Du behöver inte någon för en statisk webbplats där alla ser samma innehåll, till exempel en portfolio eller en enkel landningssida. Om du inte är säker på vad en databas egentligen är, läs först vad är en databas.

Dina alternativ

För de flesta små och medelstora webbappar är en relationsdatabas som Postgres rätt standard. Den är bra på relationer (en kund har många ordrar), håller datan konsekvent och låter dig ställa frågor senare med SQL. Se vad är Postgres för en översikt på vanlig svenska.

Beskriv din data innan du bygger

Det mest användbara du kan göra är att skriva ner de saker din app lagrar och hur de hänger ihop. Du behöver ingen databasjargong. För en bokningsapp:

• Kunder: namn, e-post, telefon
• Tjänster: namn, längd, pris
• Bokningar: vilken kund, vilken tjänst, starttid, status (väntar, bekräftad, avbokad)

Det blir tre tabeller. “Vilken kund” och “vilken tjänst” blir länkar (främmande nycklar) mellan dem. Att få detta rätt tidigt spelar långt större roll än något tekniskt val, eftersom det är svårare att ändra formen på data som redan har riktiga rader än att ändra en sidlayout.

Några tumregler:

• En tabell per typ av sak. Packa inte ordrar i en textkolumn på kunden.
• Ge varje rad ett ID och en skapad-tid. Du kommer att vilja ha båda senare.
• Använd rätt typer. Datum som datum, pengar som hela öre eller ett decimaltal, inte som text.
• Markera obligatoriska fält som obligatoriska. Låt databasen avvisa felaktig data, inte bara formuläret.

Exempelprompter

Börja med en funktion i taget i stället för att dumpa ett helt schema:

Lägg till en databas i den här appen. Skapa en tabell för bokningar med kundnamn, e-post, tjänst, starttid och status (väntar, bekräftad, avbokad; standard väntar). Spara inskick från bokningsformuläret där, visa ett bekräftelsemeddelande och lägg till en adminsida som listar bokningar, nyast först.

Sedan utöka den:

Lägg till en tabell för tjänster (namn, längd i minuter, pris i öre). Ersätt det fria textfältet för tjänst på bokningar med en länk till tjänster, och migrera befintliga bokningar utan att ta bort någon.

Och skärp den:

Se till att alla databasläsningar och -skrivningar sker på servern. Webbläsaren ska aldrig få databasens anslutningssträng. Validera e-postadressen och starttiden på servern innan något sätts in.

Steg för steg

1. Lista din data som ovan: saker, fält och länkar mellan dem.
2. Skapa databasen. I en AI-byggare begär du det i chatten. Annars skapar du en hanterad Postgres-instans och kopierar anslutningssträngen.
3. Lagra anslutningssträngen som en hemlighet (en miljövariabel på servern), aldrig i koden. Se miljövariabler och hemligheter.
4. Skapa tabellerna. Använd migreringar — versionerade skript som ändrar schemat — så att ändringar går att upprepa och återställa.
5. Bygg serverrutter som skapar, läser, uppdaterar och tar bort rader (CRUD). Webbläsaren anropar dessa rutter; den pratar aldrig direkt med databasen.
6. Koppla gränssnittet till rutterna: formulär som sparar, listor som laddas och tomma tillstånd när det inte finns något än.
7. Testa att datan finns kvar. Skicka något, ladda om sidan, öppna den i en annan webbläsare. Om datan inte finns där sparades den inte i databasen.
8. Kontrollera åtkomst. Logga in som en andra användare och bekräfta att du inte kan se eller ändra den första användarens data.
9. Publicera och testa igen på den live-URL:en, eftersom den publicerade appen kan använda en annan anslutning än din förhandsvisning.

Vanliga misstag

• Att spara i webbläsaren och tro att det sparats. localStorage verkar fungera tills någon öppnar appen på en annan enhet. Testa alltid i en andra webbläsare.
• Anslutningssträngen i frontend-koden. Vem som helst kan läsa frontend-kod. Det ger dem hela din databas.
• Inga åtkomstkontroller. “Visa mina ordrar” måste filtrera på den inloggade användaren på servern, inte i gränssnittet. Detta är den vanligaste säkerhetsbristen i AI-byggda appar; vår säkerhetschecklista går igenom den.
• Destruktiva schemaändringar. Om du ber om att “döpa om tabellen” eller “ändra strukturen” kan den tas bort och skapas om. När riktig data finns, skriv “migrera befintliga rader, ta inte bort något”.
• Att lagra filer i databasen. Bilder och PDF-filer hör hemma i fillagring, med bara deras URL eller nyckel i en tabell. Se hur du lägger till filuppladdningar.
• Inga säkerhetskopior. Ta reda på hur din plattform säkerhetskopierar data och hur du återställer den innan du har kunder.

Checklista

• Varje typ av sak har en egen tabell med ID och skapad-tid
• Obligatoriska fält och typer tvingas fram av databasen
• Anslutningssträngen finns bara i serverhemligheter
• Alla läsningar och skrivningar går via serverrutter
• Varje användare kan bara läsa och ändra sina egna rader
• Data överlever en omladdning och syns i en annan webbläsare
• Schemaändringar använder migreringar och behåller befintliga rader
• Du vet hur säkerhetskopior och återställning fungerar
• Den live-publicerade appen har testats efter publicering

Lägga till en databas i Mythex

På Mythex kan varje projekt få en egen dedikerad Postgres-databas, både på Free och Pro. Du behöver oftast inte klicka på en separat “koppla”-knapp: be om den i chatten (“spara väntelistans e-postadresser i en databas”) eller skriv /database, så injiceras anslutningsuppgifterna i arbetsytan och i din publicerade app. Projektinställningarna visar om en databas är aktiv.

Databasen somnar efter 5 minuter utan aktivitet och vaknar vid nästa förfrågan. Användning i publicerad app debiteras för den tid den faktiskt var vaken, från samma kreditsaldo som du använder för att bygga. Om du lägger till en databas efter att du redan publicerat, publicera igen så att den live-appen tar emot den.

Se Database och receptet Bygg en CRUD-app i dokumentationen. För inloggningsdelen av användarspecifik data, läs hur du lägger till inloggning i din app.

Frågor