Wie ein Datenbankdesigner denken

Wie ein Datenbankdesigner denken

Vor CREATE TABLE fragen: welche Entitäten, wie verknüpft, welche Operationen am häufigsten? Hotel: freie Zimmer, Check-in, Abrechnung, Personalberichte.

Entitäten aus dem Geschäft — Gast, Zimmer, Reservierung, Zahlung, Mitarbeiter. Attribute gehören genau einem Entität. In hotel_db teilen Rezeption, Finanzen und Housekeeping gosti, sobe, rezervacije, placanja und zaposleni — jede Änderung muss für alle Module konsistent bleiben.

Im Detail

Abfragen zuerst — Indizes folgen der Nutzung. ER-Diagramm entwickelt sich per Migration. Führen Sie das SQL-Beispiel in Workbench auf Testdaten aus, prüfen Sie EXPLAIN bei wachsenden Tabellen und dokumentieren Sie erwartete Ergebnisse.

Wichtige Punkte

• Entitäten aus Prozess. — hotel_db-Beispiel.
• Keine doppelten Attribute. — hotel_db-Beispiel.
• Abfragen treiben Indizes. — hotel_db-Beispiel.
• ER vor SQL. — hotel_db-Beispiel.
• Migrationen statt Panik-ALTER. — hotel_db-Beispiel.

Häufiger Fehler

Mit CREATE TABLE ohne Modell starten. Typische Folge: inkonsistente Daten, verlorene Reservierungen oder Check-in-Blockade in der Hochsaison — immer Backup vor Produktions-DDL/DML.

Zusammenfassung

Ein gutes hotel_db-Modell spart Monate Refactoring. Üben Sie erneut auf hotel_db, bis Sie jede Ergebniszeile erklären und mit Hotelprozessen (Check-in, Abrechnung, Reporting) verbinden können.

Hinweis: Tipp: versionierte .sql-Skripte (hotel_schema.sql, seed.sql) in Git pflegen — Reproduzierbarkeit ist wichtig, wenn mehrere am gleichen hotel_db-Modell arbeiten.