Seit Lektion M3.3 arbeiten das Windows-Programm und die neue Schicht mit einer Datenbank, und seit Lektion M3.4 liegt sie in
Azure SQL. Das ist die einfachste Form des Doppelbetriebs: Es gibt nichts zu synchronisieren, weil es nur einen Bestand gibt. Die
Tabelle in docs/datenvertrag.md sagt, wer was schreiben darf, und die Rolle AuftragsbuchNeu setzt es durch.
Diese Lektion fragt, was passiert, wenn dieser Zustand nicht reicht: Ein Datenstück soll in eine eigene Datenbank ziehen, und für einige Wochen existieren zwei Kopien, die jemand gleich halten muss. Dann entscheidet ein einziger Satz über Erfolg und Ärger: Zu jedem Datenstück gibt es zu jeder Zeit genau einen Besitzer. Alles Weitere in der Lektion ist die Umsetzung dieses Satzes. Die Muster dahinter, also Ereignisse, Nachrichten und die Konsistenz zwischen Systemen, behandelt K4, Modul 4.6; hier geht es um den Übergang im Auftragsbuch.
Zuerst die Frage: Brauchen Sie überhaupt zwei Datenbanken?
Jede zweite Datenbank ist eine Last, die Sie bis zum Abschalten tragen. Stellen Sie die Frage deshalb vor jeder Technik:
| Eine Datenbank teilen (Stand nach Lektion M3.3) | Daten in eine eigene Datenbank kopieren | |
|---|---|---|
| Aufwand | gering: Rollen, Sichten, Schutzschicht | hoch: Synchronisierung, Abgleich, Besitzwechsel |
| Konsistenz | eine Wahrheit, Transaktionen funktionieren | zwei Wahrheiten, eine davon hinkt nach |
| Eigene Regeln des neuen Systems | nur, soweit das alte Programm sie verträgt | frei wählbar, aber erst nach dem Besitzwechsel durchsetzbar (siehe unten) |
| Rückweg | Schalter umlegen | solange die Synchronisierung läuft: Besitz zurückgeben |
| Wann sinnvoll | fast immer, bis das alte Programm abgeschaltet ist | wenn das neue System unabhängig von der alten Datenbank laufen muss oder ihre Struktur nicht mehr tragen kann |
Microsofts Dokumentation zum Strangler-Fig-Muster beschreibt beide Zustände. Zuerst liest und schreibt das neue System die gemeinsame Datenbank; erst später bekommt es eine eigene Datenbank für seinen Fachbereich, die per Synchronisierung gefüllt wird, und am Ende ist sie die maßgebliche Quelle. Das Auftragsbuch bleibt so lange wie möglich im ersten Zustand. Als Beispiel für den zweiten nehmen wir den Kundenstamm: Das neue System will Kunden mit eigenen Regeln führen, zum Beispiel mit Ansprechpartnern, und eine Datenbank haben, die nicht mehr an die Tabellen des alten Programms gebunden ist.