Chaotisches Datenbankschema einer KI‑App Schritt für Schritt beheben

Wie ein chaotisches Schema bei AI‑generierten Apps aussieht

Ein chaotisches Schema wirkt oft nicht auf den ersten Blick falsch. Die App läuft, Seiten laden und Daten erscheinen. Die Probleme zeigen sich, wenn Sie etwas ändern wollen und merken, dass Sie nicht wissen, welche Tabelle die Quelle der Wahrheit ist.

AI‑generierte Prototypen erstellen oft Tabellen in Eile: eine pro Screen, Feature oder Prompt. Namen drifteten im Laufe der Zeit (User, Users, user_profiles). ID‑Formate variieren (hier Integer, dort UUID). Beziehungen werden im Code angedeutet statt in der Datenbank erzwungen.

Typische Anzeichen dafür, dass Ihr Schema Sie bereits kostet:

• Duplizierte Tabellen, die dasselbe speichern, mit leicht unterschiedlichen Spalten
• Verwirrende Identifikatoren (mehrere id‑Felder oder Fremdschlüssel als Klartext)\n- Inkonsistente Benennung (createdAt vs created_at, status vs state)\n- Spalten, die mehrere Verantwortlichkeiten mischen (Name, E‑Mail und rohes JSON zusammengepresst)\n- „Weiche Beziehungen“ (order.userId existiert, aber nichts garantiert, dass es zu einem echten Nutzer passt)

Das, was kaputtgeht, ist selten „die Datenbank“ isoliert. Es sind die Features: Login‑Sessions, die Nutzer nicht mehr zuordnen, Zahlungsaufzeichnungen, die nicht mehr korrekt joinen, Reports, die doppelt zählen, und Admin‑Screens, die auf einen alten Spaltennamen bauen.

Ein kleines Beispiel: Ein Prototyp kann sowohl customers als auch users haben, und Bestellungen verweisen manchmal auf customers.id und manchmal auf users.email. Das ist bereinigbar, aber Triage heißt zuerst Risiko senken: abbilden, was existiert, bestätigen, was die App wirklich liest und schreibt, und dann die Struktur in kleinen Schritten verbessern.

Sicherheitsvorkehrungen einrichten, bevor Sie etwas ändern

Bevor Sie Migrationen anfassen: Richten Sie Schutzmaßnahmen ein, damit ein falscher Schritt kein Ausfall wird. Viele AI‑generierte Apps funktionieren „gerade so“, weil die Daten inkonsistent sind, nicht weil das Schema solide ist. Ihre Aufgabe ist es, es sicherer zu machen, ohne das Gewohnte zu zerstören.

Starten Sie mit einem vollständigen Backup und beweisen Sie, dass Sie es wiederherstellen können. Gehen Sie davon nicht aus. Stellen Sie es in einer separaten Datenbank wieder her und starten Sie die App gegen diese Kopie. Wenn Sie nicht wiederherstellen können, haben Sie kein Sicherheitsnetz.

Erstellen Sie als Nächstes eine Staging‑Kopie, die der Produktion so genau wie möglich entspricht. Nutzen Sie dasselbe Schema, einen aktuellen Datensnapshot und dieselbe App‑Version. In Staging testen Sie Migrationen, prüfen wichtige Screens und beobachten Query‑Performance, bevor Sie echte Nutzer berühren.

Schreiben Sie die wenigen App‑Flows auf, die während Refactorings unbedingt funktionieren müssen. Kurz und spezifisch. Zum Beispiel: „sign up -> verify email -> create project“, „checkout -> payment success -> receipt“, „Admin‑Dashboard lädt unter 3 Sekunden“.

Schließlich planen Sie für jede Änderung eine Rollback‑Strategie. Wenn eine Migration halb fehlschlägt, müssen Sie wissen, ob Sie nach vorne rollen (Fix fertigstellen) oder zurückrollen (wiederherstellen und Code zurücksetzen). Eine einfache Checkliste hilft:

• Backup erstellt, Wiederherstellung getestet und Zeitstempel notiert
• Staging‑Kopie aktualisiert und App damit verbunden
• 5–10 kritische Nutzerflüsse dokumentiert und Verantwortliche zugewiesen
• Migration ist reversibel (oder es gibt einen klaren Roll‑forward‑Plan)
• Monitoring‑Notizen: welche Metriken oder Logs Erfolg bestätigen

Schritt 1: Entitäten und Beziehungen abbilden

Bevor Sie Tabellen ändern, erstellen Sie eine klare Karte dessen, was die App unter den Daten versteht. AI‑generierte Apps legen oft zusätzliche Tabellen an, die gleich klingen, aber dasselbe repräsentieren, oder mischen mehrere Konzepte in einer Tabelle. Eine einfache Karte hilft, nicht am falschen Ende zu „reparieren“.

Beginnen Sie damit, die Kern‑Entitäten in einfachen Worten aufzulisten: Nutzer, Accounts, Teams, Bestellungen, Zahlungen, Abonnements, Rechnungen, Nachrichten. Wenn Sie eine Tabelle nicht in einem Satz beschreiben können, macht sie meist zu viel.

Suchen Sie als Nächstes den Primärschlüssel jeder Tabelle. Notieren Sie, welche Spalte als echter Identifikator dient (oft id) und wo er fehlt oder unzuverlässig ist. Achten Sie auf Tabellen, die E‑Mail, Nutzernamen oder ein zusammengesetztes Feld als Identifikator verwenden. Die führen später oft zu Duplikaten.

Beziehungen skizzieren

Skizzieren Sie, wie Dinge verbunden sind:

• One‑to‑many: ein Nutzer hat viele Bestellungen
• Many‑to‑many: Nutzer können zu vielen Teams gehören (benötigt meist eine Join‑Tabelle)
• Optionale Links: eine Bestellung kann einen Gutschein haben, muss aber nicht

Wenn Many‑to‑Many als komma‑separierte IDs oder JSON‑Arrays gespeichert ist, markieren Sie es früh. Das beeinflusst jeden späteren Schritt.

Lese‑ und Schreibpfade nachverfolgen

Notieren Sie, wo die App jede Tabelle liest und schreibt: welche Screens, welche API‑Endpunkte und welche Hintergrundjobs oder geplanten Tasks. Schnell geht das, indem Sie im Codebase nach Tabellennamen und Schlüsselspalten suchen.

Beispiel: Wenn der Checkout‑Screen sowohl in orders als auch in user_orders schreibt, haben Sie wahrscheinlich konkurrierende Quellen der Wahrheit gefunden. Noch nichts zusammenführen — nehmen Sie es in die Karte auf.

Schritt 2: Duplikate und konkurrierende Quellen der Wahrheit identifizieren

AI‑generierte Apps erstellen oft dasselbe Konzept zweimal. Sie finden vielleicht customer und user oder team und org, jeweils mit eigener Tabelle und leicht unterschiedlichen Feldern. Alles wirkt in Ordnung, bis Sie Reports bauen, Berechtigungen durchsetzen oder Bugs fixen und keinen Single Source of Truth haben.

Durchsuchen Sie Ihre Schema‑Karte aus Schritt 1 und gruppieren Sie Tabellen nach Bedeutung, nicht nach Namen. Ziehen Sie ein paar Zeilen aus jeder Kandidat‑Tabelle. Sie suchen nach Stellen, an denen zwei Tabellen dasselbe reale Objekt speichern.

Häufige Duplikat‑Muster sind Identitätstabellen (customer vs user, profile vs user_details), Organisationstabellen (team vs org vs workspace), Billing‑Tabellen (invoice vs bill vs payment_request) und Adressdaten, die mehrfach auftauchen.

Suchen Sie dann nach mehreren Identifikatoren für dasselbe Objekt. AI‑Tools fügen oft mitten im Build neue IDs hinzu, sodass Sie id, user_id, uid und external_id herumliegen haben. Bugs entstehen, wenn ein Teil der App auf uid joined und ein anderer auf id und die Daten sich still aufspalten.

Achten Sie auch auf dasselbe Feld mit unterschiedlichen Namen/Formaten (createdAt vs created_at, Telefonnummer als Text und als Zahl). Selbst wenn Werte heute übereinstimmen, driftet das später.

Wählen Sie für jede Entität eine Quelle der Wahrheit und schreiben Sie sie auf. Zum Beispiel: „users.id ist der einzige interne Nutzerschlüssel; external_id ist optional und eindeutig; die Tabelle customers wird in users gemerged.“ Sie verändern noch nichts — Sie entscheiden nur, wer gewinnt, wenn Tabellen widersprüchliche Daten haben.

Schritt 3: Tabellen schrittweise normalisieren

Normalisierung bedeutet, dass jede Tabelle genau eine Sache repräsentieren sollte. Bei AI‑generierten Apps ist der schnellste Gewinn, die Teile zu entfernen, die widersprüchliche Daten erzeugen, während die App weiterläuft.

Scannen Sie zuerst nach Spalten, die mehrere Ideen mischen. Häufige Beispiele sind ein einzelnes address‑Feld mit Straße, Stadt und PLZ in einem String oder ein status‑Feld, das mehrere Bedeutungen versteckt wie „paid+shipped+refunded“. Solche Felder lassen sich schlecht validieren und schwer reporten.

Suchen Sie als Nächstes nach wiederholten Daten am falschen Ort. Ein klassischer Geruch ist eine orders‑Tabelle mit item1_name, item1_qty, item2_name oder einem JSON‑Blob von Items. Für eine Demo funktioniert das, bricht aber bei Rücksendungen, Teillieferungen oder exakten Summen zusammen.

Priorisieren Sie Normalisierung dort, wo es wehtut:

• Dateninkonsistenz (derselbe Nutzername an drei Orten, Summen, die nicht übereinstimmen)
• Reporting‑Bedarf (Finanz‑ und Ops‑Queries sind langsam oder falsch)
• Auth und Berechtigungen (Rollen werden über Tabellen kopiert)
• Alles, was Constraints blockiert (Foreign Keys noch nicht möglich)
• Schnell wachsende Tabellen (Logs, Events, Orders)

Gehen Sie schrittweise vor, um Features nicht zu brechen. Erstellen Sie neue Tabellen neben den alten, backfillen Sie die Daten und schalten Sie dann die Reads in kleinen Schritten um. Beispiel: Fügen Sie order_items hinzu, behalten Sie die bestehenden Item‑Felder und schreiben Sie neue Items kurzzeitig an beide Orte, verifizieren Sie Summen, und lassen Sie die App dann nur noch aus order_items lesen.

Schritt 4: Constraints in sicherer Reihenfolge hinzufügen

Constraints sind der Punkt, an dem „aufräumen“ in „sicher machen“ übergeht. Sie wandeln Annahmen in Regeln, die die Datenbank erzwingt. Wichtig ist, sie in der Reihenfolge hinzuzufügen, die der Realität heute entspricht — nicht dem perfekten Modell von morgen.

Beginnen Sie mit risikoarmen Regeln, die für die meisten Zeilen bereits zutreffen. Wenn eine Spalte in der Praxis immer gefüllt ist, ein NOT NULL zu setzen, fängt oft echte Bugs auf, ohne die App zu überraschen. Kleine CHECK‑Regeln sind ebenfalls nützlich, solange sie das aktuelle App‑Verhalten widerspiegeln (z. B. „status muss einer dieser Werte sein").

Bevor Sie Fremdschlüssel setzen, bereinigen Sie schlechte Zeilen. Foreign Keys schlagen fehl, wenn es verwaiste Datensätze gibt, etwa orders.user_id, die auf keinen Nutzer zeigen. Zählen Sie, wie viele Zeilen fehlschlagen würden, beheben Sie diese zuerst und erzwingen Sie dann die Beziehung.

Eindeutigkeits‑Constraints kommen danach. Sie verhindern künftige Duplikate, können aber Registrierungsflüsse oder Imports kaputtmachen, wenn die Daten noch Duplikate enthalten. Dedupe zuerst (Schritt 2), und setzen Sie Unique nur dort, wo es eine echte Geschäftsregel ist (z. B. eine E‑Mail pro Nutzer).

Wenn Sie eine neue Pflichtspalte brauchen, führen Sie sie schrittweise ein:

• Spalte als nullable hinzufügen, mit Default für neue Zeilen
• Bestehende Zeilen kontrolliert backfillen
• App aktualisieren, damit sie die neue Spalte schreibt
• Erst dann auf NOT NULL umstellen

Beispiel: In einer AI‑App ist users.email manchmal leer, die UI behandelt sie aber als Pflichtfeld. Backfillen oder die Lücken beheben, dann NOT NULL setzen und erst danach Unique auf email hinzufügen.

Schritt 5: App‑Queries aktualisieren, ohne Features zu brechen

Die meisten Ausfälle passieren genau hier, nicht in der Migration. Die App fragt noch nach alten Spalten oder schreibt an die falsche Stelle.

Beginnen Sie bei den Reads. Aktualisieren Sie SELECT‑Queries und API‑Antworten so, dass sie kurz beide Strukturen unterstützen. Das kann so einfach sein, dass Sie erst aus der neuen Tabelle lesen und bei fehlenden Daten auf die alte Spalte zurückfallen.

Sichere Reihenfolge:

• Neue Queries für das neue Schema hinzufügen, die alten weiter funktionieren lassen
• Zuerst Read‑Pfade umschalten (am besten hinter einem kleinen Feature‑Flag)
• Danach Writes migrieren, sodass neue Datensätze in die neuen Tabellen gehen
• Kurzzeitig Kompatibilität beibehalten (View, Kompatibilitäts‑Spalte oder temporäres Dual‑Write)
• Alte Queries erst entfernen, wenn Sie echten Traffic überwacht und Edge‑Cases behoben haben

Bei Writes seien Sie strikt mit Validierung. Wenn Ihr neues Schema eine Spalte in zwei Tabellen aufteilt, stellen Sie sicher, dass jeder Create/Update‑Aufruf beide Orte befüllt. Bei Dual‑Write: kurz halten undMismatchs protokollieren, damit Sie sie korrigieren können.

Beispiel: Ein Prototyp speichert den Bestellstatus in orders.status und payments.status. Lesen Sie künftig bevorzugt aus der neuen Quelle, dann ändern Sie den Checkout so, dass er nur noch das neue Feld aktualisiert, während ein temporärer Trigger die alte Spalte synchron hält.

Ein praktischer Migrationsablauf zum Wiederholen

Die sicherste Vorgehensweise sind kleine, rückgängig zu machende Schritte. Denken Sie in „eine Änderung, ein Beweis“‑Zyklen, nicht in einem Wochenende‑langen Rewrite.

Die wiederholbare Schleife

Beginnen Sie mit einer winzigen Migration, die etwas Neues hinzufügt, ohne Altes zu entfernen. Beweisen Sie, dass die App weiterhin funktioniert, und machen Sie weiter.

1. Fügen Sie die neue Tabelle/Spalte/Index hinzu (lassen Sie die alte Struktur stehen).
2. Backfillen Sie die Daten kontrolliert (in Batches, wenn die Tabelle groß ist).
3. Verifizieren Sie Counts und Beziehungen (Zeilen kopiert, FK passen, keine unerwarteten NULLs).
4. Schalten Sie zuerst die Reads um (App so aktualisieren, dass sie aus der neuen Struktur liest) und überwachen.
5. Schalten Sie die Writes um (kurzes Dual‑Write falls nötig), und entfernen Sie dann den alten Pfad.

Nach jeder Schleife führen Sie die wichtigsten Nutzeraktionen Ende‑zu‑Ende in Staging aus: Registrierung/Login, Erstellen des Kernobjekts (Order/Project/Post) und jeden Zahlungs‑ oder E‑Mail‑Schritt. Diese Flows fangen das Problem „es migriert, aber die App ist kaputt“ ein.

Performance nicht vergessen

Aufräumen kann still und leise Dinge verlangsamen. Prüfen Sie nach jeder Änderung auf neue langsame Queries, fehlende Indizes oder Queries, die keine Indizes mehr nutzen, weil sich ein Spaltentyp geändert hat.

Halten Sie eine kurze Notiz zu jeder Migration mit (a) wie man sie zurückrollt und (b) was Sie gemessen haben, um zu bestätigen, dass sie korrekt ist. Teams stecken fest, wenn zu viel auf einmal geändert wird und niemand sagen kann, welcher Schritt den Ausfall verursacht hat.

Häufige Fehler, die Ausfälle verursachen

Ausfälle passieren oft, wenn die Datenbank strikter wird, bevor die Daten bereit sind. Fremdschlüssel, NOT NULL oder Unique‑Indizes zu früh anzulegen, lässt Migrationen an bestehenden Zeilen scheitern oder die App nach Deploy Errors werfen.

Eine weitere Falle ist, die Bedeutung einer ID zu ändern. AI‑Prototypen mischen oft String‑IDs, Integer und manchmal E‑Mails als Identifikatoren. user_id von String zu Integer zu ändern (oder das UUID‑Format zu wechseln) bricht Joins, API‑Payloads, Caches und jeden Code, der die ID als String behandelt. Wenn nötig, planen Sie eine Transition mit Backfills und einer temporären Kompatibilitätsphase.

Alte Tabellen zu früh zu löschen ist ebenfalls riskant. Auch wenn die Haupt‑UI umgestellt ist, liest meist noch etwas die alte Tabelle: ein Admin‑Page, ein Webhook‑Handler oder ein nächtlicher Job.

Leicht übersehene Gefahrenzonen sind Hintergrundjobs, Admin‑Tools, Analytics‑Pipelines, Imports/Exports und mobile oder ältere Clients, die noch alte Endpunkte aufrufen.

Sicherheitsfehler können auch Ausfälle verursachen. Prototypen speichern manchmal Tokens, API‑Keys oder Passwort‑Reset‑Links im Klartext. Später fügt jemand Verschlüsselung oder kürzere Ablaufzeiten hinzu und Anmeldungen schlagen fehl. Behandeln Sie Secrets wie gefährliche Materialien: rotieren, auslaufen lassen und mit klarer Umschaltung migrieren.

Beispiel: Sie fügen einen Unique‑Constraint auf users.email hinzu, aber die Tabelle hat [email protected] und [email protected]. Produktions‑Logins schlagen fehl, weil der Bereinigungs‑ und Dedup‑Schritt übersprungen wurde.

Schnelle Checkliste vor und nach jeder Änderung

Das größte Risiko ist nicht das SQL. Es ist, Datenregeln zu ändern, während die App noch reale Flows bedient. Nutzen Sie diese Checkliste bei jeder Schema‑Änderung, auch wenn sie klein erscheint.

Bevor Sie etwas ändern

• Backup ist bestätigt und eine Wiederherstellung wurde getestet (auch lokal).
• Ihre Entitätenkarte ist aktualisiert (Tabellen, Schlüsselspalten und Beziehungen) und wurde von jemandem geprüft.
• Duplikate und konkurrierende Quellen der Wahrheit sind entfernt oder klar deprecated (keine neuen Writes).
• Sie haben die Daten‑Sauberkeit für den nächsten Constraint geprüft (Nulls, verwaiste Zeilen, ungültige Werte).
• Ein Rollback‑Plan für diese konkrete Änderung ist geschrieben (was Sie zuerst rückgängig machen und wie Sie die Sicherheit verifizieren).

Machen Sie eine kurze Pause von einer Minute und schreiben Sie den Blast‑Radius auf: welche Screens oder API‑Endpunkte brechen, wenn diese Migration fehlschlägt.

Nach der Änderung

• Führen Sie die wichtigsten Nutzerflüsse Ende‑zu‑Ende aus: Registrierung, Login und die Kern‑Transaktion der App.
• Bestätigen Sie, dass die App von der neuen Quelle der Wahrheit liest (und nicht still auf alte Spalten zurückfällt).
• Prüfen Sie, dass Constraints wirklich greifen (versuchen Sie in einer Testumgebung eine schlechte Zeile einzufügen).
• Überprüfen Sie Logs auf neue Query‑Errors und langsame Queries.
• Aktualisieren Sie die Entitätenkarte erneut, damit die nächste Änderung von der Realität ausgeht.

Beispiel‑Szenario: Users und Orders in einem Prototyp aufräumen

Ein typisches Prototyp‑Problem: Sie öffnen die DB und finden users, customers und accounts, die E‑Mail, Name und passwortähnliche Felder speichern. Bestellungen verweisen mal auf customers.id, mal auf users.id und manchmal wird nur eine E‑Mail‑String gespeichert.

Beginnen Sie damit, eine Quelle der Wahrheit für Identität zu wählen. Falls die App Login hat, ist users meist der beste Anker. Behalten Sie die anderen Tabellen vorerst, behandeln Sie sie als Profile, die später gemerged werden.

Um IDs sicher zuzuordnen, fügen Sie eine temporäre Spalte wie customers.user_id hinzu und füllen sie durch Matching auf einen stabilen Wert (oft normalisierte E‑Mail). Für Datensätze, die nicht sauber matchen, erstellen Sie eine kleine Review‑Liste und beheben diese manuell, bevor Sie Constraints hinzufügen.

Schauen Sie dann auf Bestellungen. Prototypen wiederholen oft Item‑Felder in orders (z. B. item_1_name, item_2_price) oder speichern ein JSON‑Blob mit wechselnder Struktur. Erstellen Sie eine order_items‑Tabelle mit order_id, product_name, unit_price, quantity und füllen Sie sie aus den bestehenden Daten. Behalten Sie die alten Spalten temporär, damit die App weiterläuft, während Sie Queries anpassen.

Nachdem die Daten bereinigt und gemappt sind, fügen Sie Constraints in ruhiger Reihenfolge hinzu:

• NOT NULL nur auf vollständig backfillte Felder
• Unique‑Constraints (z. B. users.email) erst nach Dedupe
• Foreign Keys (orders.user_id -> users.id, order_items.order_id -> orders.id)

Testen Sie abschließend, was Nutzer sofort spüren: Login und Passwort‑Reset, Registrierung (inkl. „E‑Mail bereits verwendet“), Bestellungen und Artikel erstellen, Checkout‑Summen und die Bestellhistorie.

Nächste Schritte: Wann Experten hinzuziehen

Wenn die Bereinigung noch in einer Sandbox läuft, können Sie meist vorsichtig vorgehen und lernen. Sobald echte Nutzer und echte Daten im Spiel sind, steigt das Risiko schnell. Eine scheinbar harmlose Migration kann Anmeldungen brechen, Bestellungen korrumpieren oder private Daten freilegen.

Holen Sie sich Experten, wenn Auth/Permissions betroffen sind, Sie Zahlungen oder Rechnungen verarbeiten, sensible Daten speichern, die App produktiv ist und Ausfall keine Option ist oder DB und App‑Logik stark verzahnt sind.

Bei Übergabe an ein Team helfen Sie schneller, wenn Sie ein Schema‑Dump und ein aktuelles Backup, eine kurze Liste kritischer Flows (Registrierung, Checkout, Refunds, Admin‑Aktionen), die größten Fehler (langsame Queries, gescheiterte Migrationen, inkonsistente Totals) und bekannte Vorfälle (Duplikate, fehlende Datensätze, Sicherheitsbedenken) teilen.

Wenn Sie mit einem kaputten AI‑generierten Prototyp arbeiten und eine End‑to‑End‑Prüfung (Schema, Logik und Sicherheit zusammen) brauchen, kann FixMyMess bei fixmymess.ai die Remediation von AI‑gebauten Apps übernehmen und mit einem kostenlosen Code‑Audit die riskantesten Punkte identifizieren, bevor Migrationen laufen.