Einleitung
Datenbank-Design ist eine der Aufgaben, bei der KI am meisten Mehrwert liefert. Schema-Erstellung, Normalisierung, Index-Strategie und Query-Optimierung folgen klaren Regeln – ideal für AI. In diesem Artikel findest du 10 Prompts für professionelles Datenbank-Design mit KI.
Inhaltsverzeichnis
- Prompt 1: Datenbank-Schema aus Anforderungen
- Prompt 2: Normalisierung prüfen
- Prompt 3: ERD (Entity Relationship Diagram)
- Prompt 4: Index-Strategie
- Prompt 5: Migrations erstellen
- Prompt 6: Query-Optimierung
- Prompt 7: NoSQL Schema Design
- Prompt 8: Seed-Daten & Testdaten
- Prompt 9: SQL → ORM Konvertierung
- Prompt 10: Performance-Audit
- Tool-Empfehlungen
- FAQ
Prompt 1: Datenbank-Schema aus Anforderungen
Dennoch solltest du einige Besonderheiten beachten.
Du bist ein Senior Database Architect. Erstelle ein Datenbank-Schema:
Projekt: [z.B. "SaaS Projektmanagement-Tool"]
Datenbank: [PostgreSQL / MySQL / SQLite]
ORM: [z.B. "Prisma" / "Drizzle" / "keins (reines SQL)"]
Funktionale Anforderungen:
- [z.B. "User können Projekte erstellen"]
- [z.B. "Projekte haben Tasks mit Status, Priorität, Zuweisung"]
- [z.B. "Teams mit Rollen (Admin, Member, Viewer)"]
- [z.B. "Kommentare auf Tasks"]
- [z.B. "Aktivitäts-Log für alle Änderungen"]
Für jede Tabelle liefere:
1. CREATE TABLE Statement mit allen Constraints
2. Begründung für jeden Datentyp
3. Primary Keys, Foreign Keys, Unique Constraints
4. Sinnvolle Default-Werte
5. created_at / updated_at Timestamps
6. Soft Delete (deleted_at) wo sinnvoll
Am Ende: Zusammenfassung aller Tabellen und Relationen.Im Grunde funktioniert dieser Ansatz mit allen gängigen AI-Tools.
Prompt 2: Normalisierung prüfen
Insbesondere für den Einstieg sind die folgenden Informationen hilfreich.
Prüfe mein Datenbank-Schema auf Normalisierung:
[Schema hier einfügen]
Analysiere:
1. Ist das Schema in 1NF? Wenn nein: Was muss geändert werden?
2. Ist es in 2NF? Gibt es partielle Abhängigkeiten?
3. Ist es in 3NF? Gibt es transitive Abhängigkeiten?
4. Sollte es in BCNF sein? Warum / warum nicht?
5. Gibt es bewusste Denormalisierung die sinnvoll ist?
Für jedes gefundene Problem:
- Beschreibe das Problem
- Zeige die Lösung (ALTER TABLE / neue Tabellen)
- Erkläre den Trade-Off (Performance vs. Sauberkeit)Darüber hinaus lässt sich das Beispiel leicht erweitern.
Prompt 3: ERD (Entity Relationship Diagram)
Vor allem für den praktischen Einsatz sind diese Informationen wertvoll.
Erstelle ein Entity Relationship Diagram für mein Schema:
[Schema oder Anforderungen hier einfügen]
Format: Mermaid.js erDiagram Syntax
Zeige:
1. Alle Entitäten mit ihren Attributen (PK, FK markiert)
2. Relationen mit Kardinalität (1:1, 1:n, n:m)
3. Junction Tables für n:m Beziehungen
4. Optionale vs. pflicht Beziehungen (||--o{ vs ||--|{)
Zusätzlich eine Text-Beschreibung jeder Relation:
"Ein User HAT VIELE Projekte"
"Ein Projekt HAT VIELE Tasks"
usw.Somit sparst du Zeit und erhältst qualitativ hochwertigeren Output.
Prompt 4: Index-Strategie
Folglich profitierst du von einem besseren Verständnis dieser Konzepte.
Erstelle eine Index-Strategie für mein Schema:
Schema:
[Schema hier einfügen]
Häufige Queries:
- [z.B. "SELECT * FROM tasks WHERE project_id = ? AND status = ?"]
- [z.B. "SELECT * FROM users WHERE email = ?"]
- [z.B. "SELECT * FROM tasks ORDER BY created_at DESC LIMIT 50"]
- [z.B. "SELECT COUNT(*) FROM tasks GROUP BY project_id, status"]
Für jeden empfohlenen Index:
1. CREATE INDEX Statement
2. Welche Query profitiert davon
3. Index-Typ (B-Tree, Hash, GIN, GiST)
4. Geschätzte Performance-Verbesserung
5. Speicherkosten des Index
Zusätzlich:
- Composite Indexes und ihre Column-Order erklären
- Partial Indexes wo sinnvoll
- Welche Indexes NICHT anlegen (over-indexing vermeiden)
- EXPLAIN ANALYZE Beispiel für vorher/nachherPrompt 5: Migrations erstellen
Grundsätzlich gibt es dabei einige Punkte zu beachten.
Erstelle eine Datenbank-Migration:
Aktuelle Schema-Version: [beschreiben oder SQL einfügen]
Gewünschte Änderung: [z.B. "Neue Tabelle 'comments', FK zu users und tasks"]
Migration-Tool: [z.B. "Prisma Migrate" / "knex" / "reines SQL"]
Anforderungen:
1. Up-Migration (Änderungen anwenden)
2. Down-Migration (Änderungen rückgängig machen)
3. Datenmigration wenn nötig (bestehende Daten transformieren)
4. Zero-Downtime: Keine langen Locks auf große Tabellen
5. Reihenfolge beachten (FK-Constraints)
Best Practices:
- Columnen immer nullable hinzufügen, dann befüllen, dann NOT NULL setzen
- Nie Column umbenennen (stattdessen: neue Column + Datenmigration + alte löschen)
- Index-Erstellung CONCURRENTLY (PostgreSQL)Außerdem kannst du den Prompt für verschiedene Programmiersprachen anpassen.
Prompt 6: Query-Optimierung
Dementsprechend solltest du die folgenden Aspekte kennen.
Optimiere diese SQL Query:
Query:
[Langsame Query hier einfügen]
EXPLAIN ANALYZE Output (wenn vorhanden):
[Output hier einfügen]
Tabellengröße: [z.B. "users: 100K, tasks: 2M, comments: 5M"]
Datenbank: [PostgreSQL / MySQL]
Analysiere:
1. Warum ist die Query langsam? (Full Table Scan? Missing Index? N+1?)
2. Optimierte Version der Query
3. Benötigte Indexes
4. Alternative Ansätze (Subquery vs JOIN, CTE vs Temp Table)
5. Caching-Strategie (Redis, Materialized View)
6. Vorher/Nachher Performance-SchätzungNatürlich solltest du den generierten Code vor dem Einsatz testen.
Prompt 7: NoSQL Schema Design
Weiterhin ist es wichtig, die Grundlagen zu verstehen.
Designst du ein NoSQL Schema:
Datenbank: [MongoDB / DynamoDB / Firestore / Redis]
Anwendung: [z.B. "E-Commerce mit Produktkatalog, Bestellungen, Reviews"]
Access Patterns (WICHTIG – NoSQL ist Query-driven!):
- [z.B. "Alle Produkte einer Kategorie anzeigen (sortiert nach Preis)"]
- [z.B. "Bestellhistorie eines Users (letzte 50)"]
- [z.B. "Top 10 Produkte nach Bewertung"]
- [z.B. "Produktdetails mit allen Reviews"]
Design-Entscheidungen:
1. Embedding vs. Referencing (mit Begründung für jeden Fall)
2. Denormalisierung: Was wird bewusst dupliziert?
3. Partition Key / Sort Key (DynamoDB) oder Collection-Strategie
4. Indexes (GSI/LSI für DynamoDB, Compound Indexes für MongoDB)
5. Consistency-Anforderungen pro Operation
6. Maximale Dokumentgröße beachten (16MB MongoDB)Insbesondere die Struktur des Prompts ist dabei entscheidend für gute Ergebnisse.
Prompt 8: Seed-Daten & Testdaten
Tatsächlich ist dieser Bereich besonders wichtig für Entwickler.
Erstelle Seed-Daten für meine Datenbank:
Schema:
[Schema hier einfügen]
Anforderungen:
1. Realistische Demo-Daten (nicht "Test User 1", "Test User 2")
2. Deutsche Namen, Adressen, E-Mails
3. Verschiedene Szenarien abdecken:
- Neuer User (keine Projekte)
- Aktiver User (viele Tasks, verschiedene Status)
- Admin User
- Edge Cases (leere Felder, maximale Länge)
4. Format: [SQL INSERT / Prisma seed.ts / JSON]
5. Menge: [z.B. "10 Users, 5 Projekte, 50 Tasks, 100 Kommentare"]
6. Beziehungen korrekt (Foreign Keys existieren)
7. Idempotent (mehrfach ausführbar ohne Fehler)Prompt 9: SQL → ORM Konvertierung
Allerdings gibt es einige wichtige Unterschiede zu beachten.
Konvertiere mein SQL-Schema zu einem ORM:
SQL-Schema:
[SQL CREATE TABLE Statements hier einfügen]
Ziel-ORM: [Prisma / Drizzle / TypeORM / Sequelize / SQLAlchemy]
Anforderungen:
1. Alle Tabellen als Models/Entities
2. Relationen korrekt definiert (1:1, 1:n, n:m)
3. TypeScript-Typen automatisch abgeleitet
4. Validierung wo möglich (z.B. Zod-Schema passend zum Model)
5. Enums als TypeScript Enums
6. Migrations-Datei für Initial Setup
7. Repository/Service Pattern als BonusDeshalb empfiehlt es sich, den Prompt schrittweise zu verfeinern.
Prompt 10: Performance-Audit
Im Grunde vereinfacht dieser Ansatz den gesamten Workflow erheblich.
Führe ein Performance-Audit meiner Datenbank durch:
Datenbank: [PostgreSQL / MySQL]
Schema: [Schema einfügen]
Bekannte Probleme: [z.B. "Dashboard lädt 5 Sekunden, /api/tasks ist langsam"]
Analysiere:
1. Schema-Probleme (fehlende Indexes, ungünstige Datentypen)
2. Query-Patterns (N+1, SELECT *, fehlende Paginierung)
3. Connection Management (Pool-Größe, idle Connections)
4. Slow Query Log analysieren
5. Table Bloat / VACUUM Status (PostgreSQL)
6. Cache-Möglichkeiten (Redis für häufige Queries)
7. Read Replicas sinnvoll?
8. Partitioning für große Tabellen?
Priorisierte Empfehlungen:
- Quick Wins (Index hinzufügen, Query umschreiben)
- Mittelfristig (Caching, Schema-Änderungen)
- Langfristig (Sharding, Read Replicas, Archivierung)Dabei zeigt dieses Beispiel den grundlegenden Ansatz.
Tool-Empfehlungen
Im Folgenden findest du alle wichtigen Details dazu.
| Tool | Zweck | AI-Unterstützung | Preis |
|---|---|---|---|
| Prisma | TypeScript ORM | Copilot generiert Schema + Queries | Kostenlos |
| Drizzle | TypeScript ORM (SQL-nah) | AI generiert SQL-basierte Queries | Kostenlos |
| DBeaver | DB GUI Client | AI Query Builder (Pro) | Kostenlos / $20/Mo |
| DataGrip | JetBrains DB IDE | AI Assistant integriert | $10/Mo |
| Supabase | Postgres + Auto-API | AI SQL Editor | Kostenlos / $25/Mo |
| PlanetScale | Serverless MySQL | Schema Insights | Kostenlos / $39/Mo |
FAQ
SQL oder NoSQL?
Darüber hinaus bietet dieser Abschnitt konkrete Beispiele und Tipps.
Für die meisten Web-Apps: SQL (PostgreSQL). NoSQL nur bei spezifischen Anforderungen: hohe Schreiblast, flexible Schemas, oder wenn das Access Pattern es erfordert (z.B. Time Series → InfluxDB, Volltextsuche → Elasticsearch).
Kann KI mein komplettes Schema designen?
Zusammenfassend lässt sich sagen, dass dies ein zentraler Aspekt ist.
Ja, für Standard-Anwendungen (CRUD, SaaS, E-Commerce) erstellt KI solide Schemas. Bei komplexen Domain-Spezifischen Anforderungen (Finanzen, Healthcare) immer von einem DB-Experten reviewen lassen.
Prisma oder Drizzle?
Natürlich gibt es dabei verschiedene Herangehensweisen.
Prisma: Einfacher Einstieg, bessere Docs, mehr Community. Drizzle: Näher an SQL, bessere Performance, mehr Kontrolle. Für neue Projekte 2026: Beides exzellent. Drizzle gewinnt bei Performance-kritischen Apps.
Wie oft sollte ich VACUUM laufen lassen?
Ebenfalls relevant sind die praktischen Anwendungsbeispiele.
PostgreSQL hat autovacuum – das reicht für die meisten Fälle. Manuelles VACUUM FULL nur bei extremem Bloat. Monitoring einrichten und autovacuum-Parameter bei Bedarf tunen.
Verwandte Artikel:
Zuletzt aktualisiert: März 2026