Wie sorge ich am besten für die Speicherung historischer Daten?

Question

Ich versuche zu bestimmen, wie ich historische Transaktionsdaten speichern soll.

Soll ich es in einer einzigen Tabelle speichern, wo der Datensatz jedes Mal mit einem neuen Zeitstempel neu eingefügt wird?

Sollte ich die historischen Daten in eine separate 'Geschichte' Tabelle brechen und nur aktuelle Daten in der 'aktiven' Tabelle behalten.

Wenn ja, wie mache ich das am besten? Mit einem Trigger, der die Daten automatisch in die History-Tabelle kopiert? Oder mit Logik in meiner Anwendung?

Update per Welbog Kommentar:

Es wird große Mengen an historischen Daten sein (Hunderttausende von Zeilen - schließlich möglicherweise Millionen)

In erster Linie Recherchen und Berichterstattung erst auf den historischen Daten ausgeführt werden .

Leistung ist ein Problem. Die Suchvorgänge sollten nicht die ganze Nacht laufen müssen, um Ergebnisse zu erzielen.

Answer 1

Wenn die Anforderung ausschließlich für die Berichterstellung gilt, sollten Sie ein separates Data Warehouse erstellen. Auf diese Weise können Sie Datenstrukturen wie sich langsam ändernde Dimensionen verwenden, die für die Verlaufsberichte viel besser sind, aber in einem Transaktionssystem nicht gut funktionieren. Die resultierende Kombination verschiebt auch die historischen Berichte von Ihrer Produktionsdatenbank, was ein Performance- und Wartungsgewinn ist.

Wenn diese Historie in der Anwendung verfügbar sein soll, sollten Sie eine Art Versions- oder logische Löschfunktion implementieren oder alles vollständig kontra- und neugestalten (d. H. Transaktionen werden nie gelöscht, einfach umgekehrt und neu formatiert). Denken Sie sehr genau darüber nach, ob Sie wirklich brauchen dies benötigen, da es eine Menge Komplexität hinzufügen wird. Das Erstellen einer Transaktionsanwendung, die den historischen Zustand korrekt rekonstruieren kann, ist erheblich schwieriger als es aussieht. Finanzielle Software (z. B. Versicherungsversicherungssysteme) versäumt es, dies viel mehr zu tun, als Sie vielleicht denken.

Wenn Sie den Verlauf ausschließlich für Audit-Logging benötigen, erstellen Sie Schattentabellen und Audit-Logging-Trigger. Dies ist viel einfacher und robuster als der Versuch, die Audit-Protokollierung in der Anwendung korrekt und umfassend zu implementieren. Die Trigger erfassen auch Änderungen an der Datenbank aus Quellen außerhalb der Anwendung.

Answer 2

Diese Frage geht entlang der Geschäftslogik. Kennen Sie zuerst Ihre Geschäftsanforderungen und starten Sie von dort aus. Ein Data Warehouse ist eine gute Lösung für diese Art von Situation. ETL bietet Ihnen viele Möglichkeiten im Umgang mit Datenflüssen. Ihr Grundkonzept von 'Geschichte' vs 'Aktiv' ist ziemlich korrekt. Ihre Verlaufsdaten werden effizienter und flexibler, wenn sie in einem Data Warehouse mit allen zugehörigen Dimensions- und Faktentabellen gespeichert werden.