Eine der wichtigsten Architekturentscheidungen die ich früh getroffen habe: Zwei getrennte Datenbanken statt einer.
MasterDB — Die Grundwahrheit
Die MasterDB enthält alle Ausgangsdaten: Ligen, Vereine, Spieler im Startzustand, Wettbewerbsregeln, Stadien. Sie ist read-only — das Spiel liest daraus, schreibt aber nie hinein. 14 Tabellen, sauber strukturiert, über den Editor pflegbar.
SaveDB — Dein Spielstand
Die SaveDB wird beim Start eines neuen Spiels aus der MasterDB generiert. Ab dann lebt sie ihr eigenes Leben: Transfers verändern Kader, Ergebnisse füllen Tabellen, Spieler entwickeln sich. 12 spielspezifische Tabellen.
Warum die Trennung?
Drei Gründe:
- Sicherheit: Egal was im Spielstand passiert — die Originaldaten sind unberührt. Korrupter Save? Neues Spiel starten, MasterDB ist intakt.
- Modding: Community-Datenbanken ersetzen die MasterDB. Dein Save bleibt davon unabhängig.
- Performance: Die MasterDB wird nur beim Spielstart gelesen. Danach arbeitet das Spiel nur mit der SaveDB — schlank und schnell.
Entity Framework Core 10 macht die Verwaltung beider Datenbanken überraschend komfortabel. Zwei DbContexte, saubere Trennung, Migration für beide separat. War die richtige Entscheidung.