hicucu/rdb-skill

Relationale Datenbank (Engine-neutral)

Überblick

Engine-neutrale Best Practices für relationale Datenbanken. Prinzipien und Muster werden einmal festgehalten; nur die Punkte, an denen SQL-Dialekte abweichen (MSSQL vs. MySQL/MariaDB), werden inline markiert oder im Dialekt-Cheatsheet zusammengefasst. Optimieren Sie auf Korrektheit und die kleinste Änderung, gestützt durch messbare Beweise.

Wann verwenden

• Entwurf oder Überprüfung eines Schemas (Tabellen, Schlüssel, Normalisierung, Datentypen).
• Hinzufügen oder Beheben von Indizes; Diagnose von langsamen Abfragen oder Full-Table-Scans.
• Lesen eines Ausführungsplans, um den Engpass zu finden.
• Auswahl oder Fehlerbehebung von Transaktionsisolation, Sperren oder Deadlocks.
• Paginierung großer Ergebnismengen; Eliminierung von N+1-Zugriffen.
• Planung einer produktionssicheren Schema-Migration.

Nicht für: tiefgehende Engine-Interna (Storage-Engine-Interna wie InnoDB-Buffer-Pool, vendorspezifische Funktionen, reine T-SQL-Konstrukte, Replikations-/Sharding-Topologie). Verwenden Sie die eigene Engine-Dokumentation oder ein dediziertes Single-Engine-Skill.

Arbeitsablauf

1. Kontext zuerst herstellen. Welche Engine + Hauptversion? Lese-/Schreibverhältnis, Zeilenvolumen, Latenzziel, OLTP vs. Analytik. Die Beratung ändert sich mit diesen Faktoren.
2. Nur die relevante Referenz lesen, die in jedem Abschnitt unten verlinkt ist.
3. Die kleinste Änderung vorschlagen, die das Problem löst, mit Abwägungen.
4. Mit Beweisen validieren — einen Ausführungsplan und Zeilen-/Zeitmetriken vorher und nachher erfassen (siehe references/execution-plans.md), nicht Faustregeln.
5. Für die Produktion, einen Rollback-Plan und eine Nachbereitung nach dem Deployment einschließen.

Schema-Design

• Beziehungen explizit modellieren; mit 3NF/BCNF normalisiert beginnen und nur mit gemessenem Grund denormalisieren. Jede Tabelle benötigt einen stabilen Primärschlüssel.
• Den schmalsten korrekten Datentyp wählen; ungültige Zustände auf Schemaebene einschränken (NOT NULL, UNIQUE, CHECK, FK) anstatt nur im Anwendungscode.

Referenzen: normalization · keys-and-constraints · data-types

Indizierung

• Spalten in WHERE, JOIN und ORDER BY indizieren — nach Selektivität, nicht nach Schätzung. Reihenfolge zusammengesetzter Indizes: Gleichheitsspalten zuerst, dann Bereich/Sortierung (Links-Präfix-Regel). Ein Bereichsprädikat stoppt die Indexnutzung für nachfolgende Spalten.
• Abdeckende Indizes vermeiden Tabellenzugriffe. Unbenutzte/doppelte Indizes prüfen und löschen; jeder Index belastet Schreibvorgänge.

Referenzen: indexing · composite-indexes

Abfrageoptimierung

• Prädikate SARGable halten — keine Funktionen/impliziten Umwandlungen auf indizierten Spalten in WHERE. Nur benötigte Spalten auswählen. EXISTS gegenüber IN (Subquery) bevorzugen, UNION ALL gegenüber UNION, wenn Deduplizierung unnötig ist, und große Schreibvorgänge bündeln.
• Keyset-Paginierung (Cursorbasiert) anstelle von großem OFFSET verwenden. N+1 durch Batching oder Joins eliminieren.

Referenzen: query-optimization · execution-plans · pagination

Transaktionen & Sperren

• Transaktionen kurz halten; I/O und langsame Arbeiten außerhalb erledigen. Zeilen in einer konsistenten Reihenfolge abrufen, um Deadlocks zu vermeiden; Deadlocks erwarten und mit Backoff wiederholen.
• Den Standard-Isolationslevel der Engine kennen (er unterscheidet sich) und die Anomalien, die jeder Level zulässt. Sperrende Lesevorgänge (FOR UPDATE) bewusst, nicht aus Gewohnheit verwenden.

Referenzen: transactions-and-isolation · locking-and-deadlocks

Migrationen & DDL

• Schemaänderungen zuerst additiv und rückwärtskompatibel gestalten; erweitern → nachbereiten → entfernen. Große/sperrende DDL benötigt eine Online-Strategie und einen Rollback-Pfad.

Referenz: migrations-and-ddl

Engine-Dialekt-Unterschiede

Auto-Inkrement, Bezeichner-Zitierung, Paginierung, Upsert, String-Funktionen, aktuelle Zeit, EXPLAIN und Isolationsstandards weichen zwischen den Engines ab. Syntax für die Zielengine bestätigen, bevor portables SQL geschrieben wird.

Referenz: engine-dialect-cheatsheet

Leitplanken

• Messbare Beweise (Ausführungspläne, Metriken) gegenüber allgemeinen Regeln bevorzugen.
• Die Engine und Hauptversion angeben, wenn das Verhalten davon abhängt.
• Explizite menschliche Zustimmung einholen vor destruktiven Operationen (DROP/DELETE/TRUNCATE oder jeder nicht rückgängig machbaren Migration). Immer bestätigen, dass ein Backup existiert.