Ich sitze gerade an einem Projekt, bei dem wir historische Bestelldaten für Analysen aufbereiten müssen. Eigentlich dachte ich, es wäre eine klassische ETL-Pipeline, aber die Datenquellen sind so fragmentiert und die Transaktionslogik hat sich über die Jahre mehrfach geändert. Jetzt frage ich mich, ob wir mit einem einfachen starren Schema überhaupt ans Ziel kommen, oder ob wir nicht eher einen Ansatz brauchen, der die verschiedenen Zustände der Daten im Zeitverlauf besser abbilden kann. Mir schwirrt da der Begriff "temporale Datenbank" im Kopf herum, aber ich bin unsicher, ob das für unseren Use Case nicht Overkill ist.
Temporale Datenbank klingt verlockend doch mich trifft eher die Frage nach der Praxis Wir reden von vielen fragmentierten Quellen unterschiedlich geaenderten Logiken und langen Wartungsfenstern Ein starres Schema mag erst bequem wirken aber mit der Zeit wächst der Zopf Rebasing Dubletten inkonsistente Historie Vielleicht hilft zuerst die wichtigsten Änderungstypen zu kartieren und zu prüfen wie oft man wirklich die Vergangenheit rekonstruieren muss
Aus technischer Sicht bietet eine temporale Modellierung mehr Spielraum aber sie ist kein Allheilmittel Man kann Valid Time und Transaction Time Konzepte nutzen um zu rekonstruieren wann Daten gueltig waren und wann sie in der Quelle geaendert wurden Praktisch koennte man mit einem zweispurigen Modell starten Eine Landing Zone fuer Rohdaten dann eine Core Temporal Schicht in der Änderungen als Versionen abgelegt werden plus einen Analytics Layer Tools wie Kafka Delta Lake oder ähnliche bleiben hilfreich aber der Fokus liegt auf Versionierung statt auf reinen Aggregationen
Ich denke direkt an eine Art Zeitreise Datenbank die einfach alles speichert und irgendwann die Queries repariert Das klingt zwar toll ist aber oft Overkill und feiert die Komplexität Vielleicht geht es eher um Governance nicht um Magie
Wie definiert man überhaupt gueltigkeitszeit bei historischen Bestelldaten und wer entscheidet dass eine fruehere Version falsch war
Statt sich zu sehr auf das Schema zu konzentrieren koennte man Ereignisströme als Treiber nehmen Bestell erstellt Status geaendert Zahlung genehmigt Man modelliert nicht die Entitaeten streng sondern die Ereignisse deren Kontext Zeitfenster und Backlog
Eine pragmatische Loesung koennte hybrid starten Behalte Kerndaten im normalisierten Modell historisiere nur wesentliche Felder mit leichter SCD Typ zwei Logik und sammle alle Ereignisse in einem Append only Log Wenn spaeter der Bedarf groesser ist kann man auf eine temporale Datenbank oder einen spezialisierten Speicher umsteigen
Vielleicht ist die zentrale Frage gar nicht ob temporale Datenbank sondern ob Historisierung wirklich fuer das Projekt noetig ist Man koennte auch eine klare Quelle der Wahrheit definieren und das Archivieren Dritten ueberlassen oder eine Minimum Versions Governance setzen Die Geschichte der Daten muss nicht alles Zeigen solange der Audit Bereich zuverlässig bleibt
