Datenbankschema-Review

Das Problem

Schema-Designfehler sind die teuersten Bugs in der Software. Ein fehlender Index fuehrt dazu, dass eine Abfrage Millionen Zeilen scannt. Ein fehlender Foreign Key erlaubt verwaiste Datensaetze, die Reports verfaelschen. Anders als Anwendungscode erfordern Schemaaenderungen an grossen Produktionstabellen sorgfaeltige Migrationsplanung — man kann es nicht einfach “spaeter beheben” ohne Ausfallrisiko.

Der Prompt

Pruefe das folgende Datenbankschema. Handle als Datenbankarchitekt, der auf Datenintegritaet, Abfrageperformance und Evolutionssicherheit bewertet.

DATENBANK: [PostgreSQL / MySQL / MongoDB / SQLite]
ERWARTETE GROESSE: [z.B. 10M Zeilen in Bestellungen, 500k Nutzer]
SCHEMA:
[CREATE TABLE Statements, Prisma Schema oder Migrationsdateien einfuegen]

HAEUFIGE ABFRAGEN:
[Die haeufigsten Abfragen einfuegen]

Bewerte in diesen Dimensionen:

1. **Normalisierung**
   - Ist das Schema in 3NF? Wenn denormalisiert, ist es begruendet?
   - Gibt es duplizierte Spalten, die auseinanderdriften?
   - Sind Many-to-Many-Beziehungen korrekt mit Junction Tables modelliert?

2. **Index-Strategie**
   - Haben alle Foreign Keys Indexes?
   - Haben WHERE-Klausel-Spalten in haeufigen Abfragen passende Indexes?
   - Gibt es Composite Indexes fuer Multi-Column-Lookups?
   - Gibt es ungenutzte oder redundante Indexes?

3. **Constraints & Integritaet**
   - Sind NOT NULL Constraints gesetzt, wo Daten erforderlich sind?
   - Sind Foreign Keys definiert (nicht nur Konvention)?
   - Sind Unique Constraints gesetzt, wo Geschaeftsregeln Eindeutigkeit verlangen?
   - Sind CHECK Constraints fuer Enum-aehnliche oder bereichsbegrenzte Werte gesetzt?

4. **Datentypen**
   - Sind Spaltentypen angemessen dimensioniert?
   - Werden Geldbetraege als DECIMAL gespeichert, nicht FLOAT?
   - Verwenden Timestamps TIMESTAMPTZ (zeitzonen-bewusst)?

5. **Abfrageeffizienz**
   - Werden haeufige Abfragen Full Table Scans ausfuehren?
   - Sind N+1-Patterns durch die Schema-Form impliziert?

Fuer jedes Problem liefere:
- **Tabelle/Spalte**: Was betroffen ist
- **Schweregrad**: Daten-Risiko / Performance / Verbesserung
- **Auswirkung**: Was bei Skalierung oder Parallelzugriff bricht
- **Fix**: DDL-Statement oder Schemaaenderung mit Migrationshinweisen

Beispielausgabe

## Schema-Review: 4 Probleme gefunden

### Daten-Risiko: Fehlender Foreign Key
Tabelle: order_items.product_id — kein FK-Constraint zu products.id
Auswirkung: Loeschen eines Produkts hinterlaesst verwaiste Bestellpositionen.
Fix:
  ALTER TABLE order_items ADD CONSTRAINT fk_order_items_product
  FOREIGN KEY (product_id) REFERENCES products(id) ON DELETE RESTRICT;

### Performance: Fehlender Index bei haeufiger Abfrage
Tabelle: orders — Abfrage `SELECT * FROM orders WHERE user_id = ? AND status = ?`
Fix: CREATE INDEX idx_orders_user_status ON orders(user_id, status);

### Verbesserung: Float fuer Waehrung
Tabelle: products.price FLOAT
Auswirkung: Fliesskomma-Arithmetik: 0.1 + 0.2 = 0.30000000000000004
Fix: ALTER TABLE products ALTER COLUMN price TYPE DECIMAL(10,2);

Wann verwenden

Vor dem Erstellen von Migrationsdateien, beim Onboarding in eine Legacy-Datenbank oder bei Performance-Untersuchungen ausfuehren. Besonders wertvoll, bevor die Datenbank den Punkt uebersteigt, an dem ALTER TABLE eine mehrstuendige Operation wird.

Profi-Tipps

• Abfragen einbeziehen — Schemaqualitaet ist bedeutungslos ohne zu wissen, wie auf Daten zugegriffen wird.
• Skalierung angeben — Index-Empfehlungen fuer 10.000 Zeilen unterscheiden sich drastisch von 10.000.000 Zeilen.
• Migrationsskripte anfordern — “Generiere sichere Migrations-SQL fuer jeden Fix mit Zero-Downtime-Patterns.”
• ORM-generierte Schemata reviewen — ORMs wie Prisma treffen Schema-Entscheidungen, die man ueberpruefen sollte.