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

1. Prompt 1: Datenbank-Schema aus Anforderungen
2. Prompt 2: Normalisierung prüfen
3. Prompt 3: ERD (Entity Relationship Diagram)
4. Prompt 4: Index-Strategie
5. Prompt 5: Migrations erstellen
6. Prompt 6: Query-Optimierung
7. Prompt 7: NoSQL Schema Design
8. Prompt 8: Seed-Daten & Testdaten
9. Prompt 9: SQL → ORM Konvertierung
10. Prompt 10: Performance-Audit
11. Tool-Empfehlungen
12. 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/nachher

Prompt 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ätzung

Natü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 Bonus

Deshalb 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.

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:

• 50 ChatGPT Prompts für Entwickler
• Ferner AI für DevOps & CI/CD
• Clean Code mit AI schreiben

Zuletzt aktualisiert: März 2026

Der Beitrag AI-gestütztes Datenbank-Design erschien zuerst auf MetinCelik.de.