Seit Modul 4.12 besitzt jeder Dienst seine Daten. Das ist gut für die Dienste und schlecht für eine Frage, die die Inhaberin eines Büros jeden Monat stellt: „Wie viele Termine wurden gebucht, wie viele davon online, und wie viele Angebote gingen raus?“ Die Antwort berührt Termine, Angebote und Vertrieb, also mehrere Kontexte und bald mehrere Datenbanken. Lektion 4.12.3 hat deshalb gesagt: Berichte über alle Dienste brauchen eine eigene Architektur. Dieses Modul baut sie. Es beginnt mit der Grundunterscheidung der Datenarchitektur: Transaktionen und Auswertungen sind zwei verschiedene Arten von Arbeit und wollen verschieden gespeichert werden.

Ein Wort vorab zur Technik: In der Welt der Auswertungen ist Python verbreitet, auch in Microsoft Fabric. Dieser Kurs bleibt bei T-SQL und Spark SQL. Was Sie hier über Schemas, Ladungen und Entscheidungen lernen, hängt nicht an der Sprache.

Zwei Arten von Last

OLTP (Transaktionen) OLAP (Auswertungen)
Frage „Ist dieser Termin noch frei?“, „Lege dieses Angebot an.“ „Wie viele Buchungen je Büro und Monat, im Vergleich zum Vorjahr?“
Zugriff viele kleine Lese- und Schreibvorgänge, je wenige Zeilen wenige große Lesevorgänge über viele Zeilen und wenige Spalten
Modell normalisiert: jede Tatsache an einem Ort, Schreiben ohne Widersprüche denormalisiert als Sternschema: einfach zu lesen, schnell zu summieren
Speicherung zeilenweise (Rowstore): eine Zeile liegt beisammen spaltenweise (Columnstore): eine Spalte liegt beisammen und lässt sich gut komprimieren
Zeit der aktuelle Stand; Altes wird überschrieben Geschichte: Was galt wann?
Wer die Kladde selbst, ihre Grains und Endpunkte Berichte, Auswertungen, Planung

Beide Arten von Last vertragen sich schlecht auf derselben Datenbank. Eine Auswertung über ein Jahr liest Hunderttausende Zeilen und konkurriert mit jeder Buchung um Arbeitsspeicher, Prozessor und Sperren. Seit Lektion 4.4.4 hat die Kladde READ_COMMITTED_SNAPSHOT an, so blockieren Leser die Schreiber nicht mehr; um die Ressourcen konkurrieren sie trotzdem.