Databaseproblemer i AI-genererte apper
Flate skjemaer, manglende indekser, N+1-spørringer. Hvorfor AI-generert databasekode bryter sammen under ekte trafikk.
Hva går galt med databasen?
AI genererer et databaseskjema som ser riktig ut ved første øyekast. Du har tabeller, kolonner, data lagres. Problemet er at skjemaet er flatt. Kundenavn, e-post og telefonnummer lagres direkte på hver bestilling i stedet for å lenkes til en brukertabell. Med 10 testposter merker ingen noe. Med ekte trafikk begynner ting å knekke.
Dataduplisering er overalt. Å endre en kundes e-post betyr å oppdatere hundrevis av rader i stedet for én. Dette er klassiske oppdateringsanomalier — et problem som ble løst innen databaseteknikk for tiår siden, men AI vet ikke om det fordi den genererer kode som «fungerer», ikke kode som er korrekt.
I tillegg mangler det indekser. En spørring som burde ta 50ms tar 3 sekunder. Databasen skanner hele tabellen rad for rad fordi ingen sa til AI at den skulle legge til en indeks på kolonnen du filtrerer på.
Hvorfor AI gjør databasedesign feil
AI-verktøy er trent på kode som «fungerer» — ikke på kode som er optimalisert for belastning. De genererer skjemaer som ser bra ut i en demo, men kollapser under produksjonstrafikk. Ingen normalisering, ingen indekser, ingen tanke på hvordan dataene vil vokse.
Det klassiske N+1-problemet: AI genererer kode som henter en liste med bestillinger, og deretter kjører en separat databasespørring for hver bestilling for å hente kundedata. 100 bestillinger = 101 databasespørringer. Dette burde være en eneste spørring med en JOIN.
Så mangler det connection pooling. Hver HTTP-forespørsel åpner en ny databasetilkobling. Med 50 samtidige brukere begynner databasen å avvise tilkoblinger fordi grensen er nådd. AI tenker ikke på å dele tilkoblinger — den bare kobler til og går videre.
Hvordan fikse det
- Skjemagjennomgang. Jeg går gjennom hele databasen og identifiserer flate strukturer, manglende relasjoner og duplisert data. Jeg designer et normalisert skjema som eliminerer oppdateringsanomalier.
- Legge til indekser. Jeg analyserer spørringer og legger til indekser på kolonner som brukes i
WHERE,JOINogORDER BY. Spørringer som tok sekunder går ofte på titalls millisekunder når indeksene er på plass. - Fikse N+1-spørringer. Jeg erstatter løkker med individuelle spørringer med effektive
JOIN-er eller batch-spørringer. 101 spørringer blir til én. - Connection pooling. Jeg konfigurerer en tilkoblingspool slik at databasen ikke drukner i nye tilkoblinger ved hver forespørsel.
- Databasemotormigrering. Hvis den nåværende databasen ikke passer brukstilfellet (f.eks. SQLite i produksjon), migrerer jeg til PostgreSQL eller MySQL — motorer designet for å håndtere samtidig trafikk.
Les også
- Treg backend i AI-genererte apper — databaseproblemer er den vanligste årsaken til treg backend. Lær andre feilkilder.
- Skaleringsproblemer i AI-genererte apper — en dårlig designet database er den første skaleringsbarrieren. Lær hvordan du fikser det.
Bremser databasen ned appen din?
Jeg gjennomgår skjemaet, identifiserer flaskehalser og fikser dem. Spørringer som tok sekunder går ofte på titalls millisekunder når indeksene er på plass.
Bestill en gratis samtale →