Wie man App-Datenbanken mit KI generiert, ohne Datenbankregeln zu verletzen

Sie haben wahrscheinlich schon Demos von KI-gestützten Code-Generatoren gesehen. Man gibt einen Prompt wie “baue ein Multi-Tenant Project Management SaaS” ein, und wenige Minuten später hat man ein schönes Dashboard, einen Frontend-Router und ein im Hintergrund generiertes Datenbankschema. Es wirkt unglaublich schnell, aber sobald man unter die Haube schaut - besonders auf das Datenbankschema - zeigen sich die Risse in der Magie.

Large Language Models (LLMs) sind exzellent darin, Texte vorherzusagen und UI-Komponenten zu schreiben, aber sie verstehen keine relationale Algebra. Wenn ein KI-Agent eine Datenbank aufsetzt, optimiert er für den einfachsten Weg, um ein visuelles Element darzustellen. Das Ergebnis ist fast immer eine Sammlung flacher, denormalisierter und fragiler Tabellen, die in dem Moment zusammenbrechen, in dem echte Produktionsdaten geladen werden.

Wenn Sie eine Anwendung mit modernen KI-Code-Generatoren wie Bolt oder Lovable bauen, können Sie es sich nicht leisten, der KI willkürliche Datenbankentscheidungen zu überlassen. Sie müssen sie führen. Sie können Prompts schreiben, die die KI zwingen, klassische Datenbankregeln einzuhalten, Ihre relationalen Schemata sauber zu halten und die Datenintegrität zu schützen.

Warum LLMs beim relationalen Datenbankdesign scheitern

Datenbank-Engines arbeiten nach strikter, mathematischer Mengenlehre. Um Datenanomalien, Update-Konflikte und langsame Abfragen zu vermeiden, benötigt eine Datenbank ein strukturiertes relationales Modell. LLMs hingegen arbeiten mit semantischer Wahrscheinlichkeit. Sie schreiben Schemata basierend darauf, was im Code visuell plausibel aussieht, was zu drei häufigen Architekturfehlern führt.

Die Falle der denormalisierten flachen Tabelle

KI-Tools hassen es, Join-Tabellen zu erstellen. Für ein LLM ist es viel einfacher, eine einzige users-Tabelle zu bauen und eine Liste von kommagetrennten String-Tags direkt in ein Textfeld zu quetschen, als eine ordentliche Junction-Tabelle einzurichten. Wenn Ihr Frontend Benutzer nach ihren Tags filtern muss, schreibt die KI komplexe, nicht indexierte reguläre Ausdrücke, um dieses Textfeld zu parsen. Dieser Ansatz funktioniert gut mit drei Testdatensätzen im Browser, aber er wird Ihre Datenbank-CPU in die Knie zwingen, sobald Ihre Nutzerbasis wächst.

Umgehung von Constraints

In einer relationalen Datenbank sind Constraints Ihre letzte Verteidigungslinie. Sie verhindern leere Datensätze, garantieren eindeutige E-Mails und stellen sicher, dass beim Löschen eines Parent-Datensatzes auch die Child-Datensätze bereinigt werden. Da Constraints eine strikte logische Konfiguration erfordern, lassen KI-Generatoren sie regelmäßig weg. Sie erstellen Tabellen ohne Primary Keys, lassen NOT NULL-Flags bei Pflichtfeldern weg und ignorieren Foreign Keys komplett. Das macht die Datenbank extrem fragil - ein einziger Bug in Ihrer Anwendungsschicht kann Ihren gesamten Datensatz korrumpieren.

Schema-Drift und Regressionsschleifen

Wenn Sie Ihren KI-Builder inkrementell Datenbankänderungen generieren lassen, während Sie das Frontend visuell anpassen, werden Sie schnell auf Schema-Drift stoßen. Die KI schreibt eine neue Migrationsdatei, die mit Ihren bestehenden Tabellen kollidiert, löscht Spalten mit echten Daten, um einen Namenskonflikt zu lösen, oder erstellt redundante Tabellen, um eine neue visuelle Komponente zu unterstützen.

Um diese Probleme zu vermeiden, müssen Sie relationale Datenbankregeln bereits ab dem ersten Prompt erzwingen.

Regel 1: Erzwingen Sie die dritte Normalform (3NF)

Damit Ihre Daten sauber bleiben und Abfragen schnell ausgeführt werden, müssen Ihre Tabellen normalisiert sein. Normalisierung ist der Prozess der Datenorganisation, um Redundanzen und Abhängigkeiten zu minimieren. In einer professionellen Anwendung sollten Sie die Dritte Normalform (3NF) anstreben.

Um von einer KI normalisierte Tabellen zu erhalten, müssen Sie explizit definieren, wie sie mit Attributen umgehen soll:

• Erste Normalform (1NF): Jede Spalte muss atomare (unteilbare) Werte enthalten. Die KI darf niemals kommagetrennte Listen, JSON-Arrays oder semistrukturierte Strings in einem einzelnen Datenbankfeld speichern.
• Zweite Normalform (2NF): Alle Nicht-Schlüssel-Attribute müssen vollständig vom Primärschlüssel abhängig sein. Wenn eine Tabelle einen zusammengesetzten Schlüssel hat, muss sich jede Spalte auf den gesamten Schlüssel beziehen, nicht nur auf einen Teil davon.
• Dritte Normalform (3NF): Keine Spalte darf von einer anderen Nicht-Schlüssel-Spalte abhängen (keine transitiven Abhängigkeiten). Wenn Sie beispielsweise eine projects-Tabelle haben, speichern Sie den Namen und die Telefonnummer des Kunden nicht direkt darin. Das Projekt sollte über einen Fremdschlüssel auf eine clients-Tabelle verweisen, in der die Kundendaten hinterlegt sind.

Das Template für den Normalisierungs-Prompt

Wenn Sie eine Datenbank mittels SQL DDL initialisieren oder Ihren AI Builder anweisen, nutzen Sie eine explizite Systemregel:

“Entwirf beim Erstellen des relationalen Datenbankschemas alle Tabellen in der Dritten Normalform (3NF). Verwende keine JSON-Arrays, JSONB-Spalten oder kommagetrennte Textfelder, um mehrwertige Attribute oder Relationen zu speichern. Extrahiere diese stattdessen in normalisierte Kindtabellen oder Junction-Tabellen mit Fremdschlüssel-Constraints. Stelle sicher, dass Nicht-Schlüssel-Attribute strikt vom Primärschlüssel abhängen und transitive Abhängigkeiten vermieden werden.”

Indem Sie die KI auf diese Einschränkungen festlegen, verhindern Sie, dass sie Abkürzungen nimmt, nur um den Entwicklungsaufwand auf der UI-Seite zu gering zu halten.

Regel 2: Datenintegritäts-Constraints explizit definieren

Eine Datenbank ohne Constraints ist eine tickende Zeitbombe. Wenn Sie eine Datenbank wollen, die sauber und konsistent bleibt, müssen Sie die KI anweisen, explizite Regeln direkt in die SQL-Schema-Definition zu schreiben.

Primär- und Fremdschlüssel

Verlangen Sie immer, dass jede Tabelle einen einzigen, klar definierten Primärschlüssel hat. Für moderne Webanwendungen werden UUIDs gegenüber autoincrementierenden Integern bevorzugt, da sie ID-Enumeration-Angriffe verhindern und es ermöglichen, IDs sicher auf der Client-Seite zu generieren, bevor sie in die Datenbank geschrieben werden.

Darüber hinaus muss jede Relation explizite Fremdschlüssel verwenden. Wenn eine tasks-Tabelle ein project_id-Feld hat, muss dieses Feld direkt auf die projects-Tabelle verweisen. Weisen Sie die KI zudem an, das Löschverhalten zu spezifizieren:

• Nutzen Sie ON DELETE CASCADE, wenn der Kinddatensatz gelöscht werden soll, sobald der Elternsatz gelöscht wird (z. B. sollte das Löschen eines Projekts auch dessen Aufgaben löschen).
• Nutzen Sie ON DELETE RESTRICT oder ON DELETE SET NULL, wenn die Kinddatensätze erhalten bleiben sollen (z. B. sollte das Löschen eines Benutzers nicht die Historie der von ihm erstellten Team-Logs löschen).

Not Null, Unique und Check Constraints

Lassen Sie die KI niemals Spalten erstellen, die standardmäßig NULL-Werte akzeptieren, es sei denn, das Feld ist tatsächlich optional. E-Mail-Felder, Benutzernamen und Organisations-IDs sollten immer als NOT NULL definiert sein.

Unique-Constraints sollten explizit für Felder wie E-Mails, Token oder benutzerdefinierte Slugs gesetzt werden. Schließlich sind Check-Constraints (CHECK) äußerst nützlich, um ungültige Datenzustände zu verhindern, bevor sie Ihre Tabellen erreichen. Beispielsweise sollte eine status-Spalte auf eine bestimmte Liste von Strings beschränkt sein (wie pending, active oder archived).

Das Template für den Integritäts-Prompt

Integrieren Sie diese Regeln in Ihren Generierungsprozess:

“Definiere für jede Datenbanktabelle einen Primärschlüssel mittels UUIDs. Jede Relation muss durch einen Fremdschlüssel-Constraint erzwungen werden, wobei die Löschrichtlinie explizit angegeben wird (nutze CASCADE für untergeordnete Ressourcen und RESTRICT oder SET NULL für unabhängige Entitäten). Wende NOT NULL auf alle Pflichtfelder an. Nutze UNIQUE-Constraints für eindeutige Identifikationsspalten und CHECK-Constraints, um Status-Spalten auf gültige String-Sets zu beschränken.”

Regel 3: Relationale Junction-Tabellen entwerfen

Many-to-Many-Beziehungen sind eine häufige Fehlerquelle bei KI-Generatoren. Wenn Benutzer mehreren Workspaces angehören können oder Projekte mehrere Tags haben können, benötigen Sie eine Junction-Tabelle, um diese zu verbinden.

Eine ordnungsgemäße Junction-Tabelle sollte enthalten:

• Einen Fremdschlüssel, der auf die erste Tabelle verweist.
• Einen Fremdschlüssel, der auf die zweite Tabelle verweist.
• Einen zusammengesetzten Primärschlüssel aus beiden Fremdschlüsseln, um doppelte Beziehungen zu verhindern.
• Kaskadierende Löschregeln, sodass das Entfernen eines Benutzers oder Workspaces automatisch den entsprechenden Eintrag in der Junction-Tabelle bereinigt.

Wenn Sie Ihre KI prompten, wird diese oft versuchen, diese Struktur zu umgehen, da das Management von Joins in React-Komponenten etwas mehr Frontend-Code erfordert. Widerstehen Sie dem. Zwingen Sie die KI zur Verwendung von Junction-Tabellen und lassen Sie sie die relationalen Abfragen schreiben (mittels JOIN-Statements in SQL oder relationalen Abfragen in Supabase-Client-Libraries), um die Daten zu laden.

Der Workflow für pragmatische Builder: Schema First

Um die volle Kontrolle über Ihre Anwendung zu behalten, sollten Sie das Datenbankdesign von der Frontend-Entwicklung trennen. Einer KI das Datenbankschema schreiben zu lassen, während sie gleichzeitig Ihre Buttons entwirft, führt unweigerlich zu Regression-Loops.

Folgen Sie stattdessen diesem Workflow:

1. Zuerst das Schema entwerfen: Lassen Sie die KI eine rohe SQL-DDL-Datei basierend auf den beschriebenen Regeln schreiben.
2. SQL manuell prüfen: Stellen Sie sicher, dass jede Tabelle normalisiert ist, Constraints definiert sind und Indizes für Fremdschlüssel gesetzt wurden.
3. Migrationen ausführen: Führen Sie das SQL-Skript direkt in Ihrem Datenbank-Editor aus (z. B. im Supabase SQL Editor).
4. Schema in Ihren Builder importieren: Sobald die Tabellen in Ihrer Datenbank live sind, weisen Sie Ihren AI Builder (wie Lovable oder Bolt) an, das bestehende Schema zu lesen, anstatt ein neues zu generieren.

Dieser Schema-First-Ansatz stellt sicher, dass Ihre Datenbank sauber, standardisiert und vollständig strukturiert bleibt, selbst wenn die KI den Frontend-Code schreibt.

Eine Alternative: Strukturiertes No-Code ohne Datenbank-Overhead

Die Verwaltung von SQL-Migrationen, Fremdschlüssel-Constraints und normalisierten Strukturen erfordert viel Entwickleraufwand, selbst mit KI-Unterstützung. Wenn Sie interne Geschäftstools, Verzeichnis-Seiten oder Kundenportale bauen, müssen Sie nicht immer eine rohe Postgres-Datenbank verwalten.

Hier bieten strukturierte visuelle Builder wie Softr einen anderen Ansatz. Anstatt SQL-DDL zu schreiben, können Sie Ihre Anwendung direkt mit strukturierten Datenplattformen wie Airtable, Google Sheets oder SmartSuite verbinden.

Dieses Modell bietet mehrere deutliche Vorteile:

• Visuelles Beziehungsmanagement: Sie können relationale Felder (z. B. die Verknüpfung eines Kunden mit einem Projekt) visuell in Ihrer Datenquelle einrichten, ohne sich um SQL-Junction-Tabellen oder Löschrichtlinien für Fremdschlüssel kümmern zu müssen.
• Granulare Benutzerberechtigungen: Softr verwaltet Benutzerberechtigungen und Rollen visuell im Editor. Das bedeutet, Sie müssen keine komplexen Datenbank-Sicherheitsrichtlinien (wie Postgres Row Level Security) schreiben, um Kundendaten privat zu halten.
• Vorhersehbare Entwicklung: Da Sie vorgefertigte Komponenten konfigurieren, anstatt ein LLM zum Regenerieren von Code zu prompten, vermeiden Sie die Regression-Loops, die generierte Apps oft plagen. Sie können Ihr Layout ändern oder neue Datenbankfelder hinzufügen, ohne das Risiko einzugehen, bestehende Abfragen zu beschädigen.

Wenn Sie ein hochgradig individuelles SaaS-MVP mit komplexen Hintergrundberechnungen benötigen, ist das Prompting von Datenbankschemata für ein Postgres-Backend der richtige Weg. Wenn Sie jedoch ein operationales Tool bereitstellen müssen, erspart Ihnen ein strukturiertes Tool wie Softr Stunden an Datenbankwartung.