Vad är en databas? En guide för dig som bygger appar

En databas är en ordnad lagring av information som en app sparar till och läser från: dess användare, beställningar, bokningar, meddelanden. Till skillnad från information som bara finns i en webbläsarflik finns data i en databas kvar efter en omladdning eller omstart, och alla som använder appen ser samma poster. De flesta databaser organiserar data i tabeller, ungefär som blad i ett kalkylblad, men med strikta regler som håller datan konsekvent.

Varför det spelar roll när du bygger med AI

Den vanligaste överraskningen för den som bygger med AI är en app som ser färdig ut men glömmer allt. Du lägger till en kund, laddar om sidan och den är borta. Det betyder oftast att appen höll data i webbläsarens minne i stället för i en databas.

En databas är också där många av de viktigaste besluten finns, oavsett om du inser det eller inte:

• Vad du registrerar. Om du inte lagrar en boknings status kan du inte visa vilka bokningar som avbokats.
• Hur saker hänger ihop. Om en kund kan ha många bokningar, eller en bokning många tjänster, formar det hela appen.
• Vem som får se vad. De flesta integritetsmisstag handlar om vilka poster en användare kan läsa.

Du behöver inte designa databasen själv. Men att förstå grunderna låter dig beskriva din data tydligt och upptäcka problem tidigt.

En vardaglig jämförelse

Tänk dig ett välordnat arkivskåp på ett litet kontor.

Varje låda innehåller en sorts sak: en låda för kunder, en för möten, en för fakturor. Inuti varje låda följer varje mapp samma format, med samma fält ifyllda. Varje mapp har ett unikt referensnummer, och när en faktura tillhör en kund noterar fakturamappen kundens nummer i stället för att kopiera hela kundakten.

Det är en relationsdatabas. Lådorna är tabeller, mapparna är rader, fälten är kolumner, referensnumren är primärnycklar och noteringarna som pekar till en annan mapp är främmande nycklar. En bra kontorschef upprätthåller också regler: inget möte utan datum, inga två kunder med samma nummer, precis som en databas gör.

Ett genomgånget exempel: en bokningsapp för en frisersalong

Säg att du ber en AI bygga en bokningssida för en frisersalong. En rimlig databas skulle ha fyra tabeller.

services

staff

customers

bookings

Titta på tabellen bookings. Den kopierar inte Lenas namn och telefonnummer till varje bokning; den lagrar customer_id = 101. Om Lena byter telefonnummer ändras det på ett enda ställe, och varje bokning visar det nya. Det är kärnidén i en relationsdatabas: lagra varje fakta en gång och länka till den.

Samma struktur besvarar användbara frågor:

• “Vilka tider är lediga för Omar på fredag?” Titta på Omars bokningar den dagen.
• “Hur mycket tjänade färgningar den här månaden?” Koppla bokningar till tjänster och summera priserna.
• “Vilka kunder har inte bokat på 90 dagar?” Jämför kunder med deras senaste bokning.

Vanliga begrepp förklarade

Typer av databaser

För nästan allt en grundare eller ett litet företag bygger först är en relationsdatabas det säkra valet.

Var databasen sitter i din app

Besökare pratar aldrig direkt med databasen. Sidan i deras webbläsare (frontend) ber din server (backend) om data, oftast via ett API. Servern kontrollerar vem som frågar och om de får, frågar sedan databasen och skickar tillbaka bara det den personen ska se.

Det mellersta steget är viktigt. Om webbläsaren kunde fråga databasen direkt med full åtkomst kunde vem som helst öppna utvecklarverktygen och läsa allt.

Vanliga misstag och missuppfattningar

• Att bara lagra data i webbläsaren. Webbläsarlagring (som localStorage) finns på en enhet och i en webbläsare. Det är bra för ett sparat filter, inte för beställningar.
• Att stoppa allt i en enda tabell. En enda tabell “bookings” med kundens namn, telefon och tjänstepris kopierade i varje rad blir osynkad snabbt.
• Att lagra lösenord som klartext. Lösenord ska hashas, aldrig lagras läsbara. Se vad autentisering är.
• Inga regler för datan. Utan obligatoriska fält och unikhetsregler får du bokningar utan datum och dubbletter av kunder.
• Att glömma radering. Bestäm om en raderad kund också raderar deras bokningar, behåller dem eller blockeras.
• Att använda produktionsdata för experiment. Testa riskfyllda ändringar någon annanstans först, och behåll säkerhetskopior.
• Att för alltid behandla kalkylbladet som databas. Kalkylblad är bra för en början, men de klarar dåligt många samtidiga användare och behörigheter. Se hur du gör om ett kalkylblad till en app.

Vad du ska be din AI-byggare om

• “Spara detta i en databas, inte i webbläsaren. Berätta vilka tabeller du kommer att skapa.”
• “Visa schemat som en enkel tabell: varje tabell, dess kolumner och hur de länkar.”
• “En kund kan ha många bokningar; varje bokning har exakt en tjänst och en personal.”
• “Gör e-post obligatoriskt och unikt för kunder.”
• “Stoppa två bokningar för samma personal från att överlappa.”
• “Bara den inloggade ägaren får läsa alla bokningar; kunder ser bara sina egna. Upprätthåll det på servern.”
• “När jag raderar en tjänst, radera inte tidigare bokningar. Markera tjänsten som inaktiv i stället.”

Databaser i Mythex

När din app behöver spara data lägger Mythex till en dedikerad Postgres-databas i projektet. Du kan be om det i chatten (“spara väntelistans registreringar i en databas”) eller använda kommandot /database. Anslutningsuppgifterna skickas automatiskt till din app, och agenten skapar tabellerna. Databasen somnar efter fem minuters inaktivitet och vaknar vid nästa förfrågan, och publicerad användning debiteras för den tid den var vaken, från samma kreditsaldo som bygget. Den finns på Free och Pro. Dokumentationen om databaser beskriver detaljerna, och app-mallarna innehåller datadrivna startpunkter.

Frågor