Datenbank-Snapshots / Revisionen

Ich suche nach einem geeigneten Prozess, um Revisionen oder Snapshots von Zeilen (und deren Beziehungen) in einer Datenbank zu behalten.

Nehmen Sie zum Beispiel eine eCommerce-Plattform -

• Ein Kunde erstellt eine Bestellung. Die Bestellung ist mit einer Rechnungsadresse und einer Lieferadresse verknüpft.
• Der Kunde ändert dann die Adresse in seinem Adressbuch in seinem Profil.
• Die Adresse sollte sich nicht für die ursprüngliche Reihenfolge ändern.

Ich habe mir ein paar Konzepte angeschaut, von denen eines die Duplikat-Tabellen ist, das andere die temporalen Datenbanken und das andere eine Revisions-ID und ein aktives Flag.

Obwohl ich weiß, dass mir niemand die beste / geeignetste Lösung für meine Anwendung nennen kann, da es eine Frage der Meinung usw. ist, hatte ich gehofft, dass jemand möglicherweise die Vorteile / Nachteile im Vergleich demonstrieren könnte. Ich habe viele Fragen zu SO gelesen und ein paar Artikel zu den verschiedenen Implementierungen, aber keiner vergleicht wirklich jede Idee oder gibt an, wo sie am besten geeignet sind. Im Folgenden habe ich mein Verständnis für jedes der Konzepte dargelegt.

Tabellen duplizieren

Speichern Sie die Informationen in Zeilen, die für die Daten relevant sind, mit denen sie einen Snapshot erstellen müssen. I.e. Behalten Sie eine Adresse in Spalten in der Bestellungstabelle eines Online-Shops.

Vorteile

• Die Daten sind in eindeutig relevante Tabellen aufgeteilt, keine Joins usw. erforderlich.
• Es müssen nicht nur aktive Zeilen ausgewählt werden, wie in den folgenden Konzepten erforderlich.
• Unter der Annahme, dass Zeilen mit Zeitstempeln versehen sind, werden die meisten Vorteile der temporären Datenbank beibehalten

Nachteile

• Duplizierung
  • des Schemas (besonders problematisch, wenn mehrere Tabellen eine Revision durchführen)
  • von Modellen bei Verwendung eines ORM.
  • von Daten, wenn sich Daten eines Schnappschussstücks nicht geändert haben und wiederverwendet werden. I.e. wenn 10 Bestellungen gemacht werden, wird die Adresse 11 Mal gespeichert (Bestellungen + aktuelle)
• Zusätzlicher Code, der erforderlich ist, um die Einfügungen in relevante Tabellen zu übernehmen.

Temporäre Datenbanken / Aktives oder aktuelles Zeilenflag

Datenbankzeilen, die "zeitbewusst" sind, d. h. ihr Kontext ist die Zeit zwischen zwei Datumsangaben. Daten können verknüpft werden, wenn der Zeitkontext zwischen dem der temporalen Tabelle liegt.

Vorteile

• Keine Duplizierung von Schemas oder Modellen. Änderungen an einem Ort vorgenommen.
• Das ORM-Modell kann mit der Erstellung einer neuen Zeile umgehen und diese nahtlos als aktiv markieren.
• Keine Replikation von Zeilen, in denen keine Änderungen vorgenommen wurden. I.e. 10 Bestellungen an 1 Adresse speichern die Adresse einmal.

Nachteile

• Abfragen werden komplexer, da Joins / where-Klauseln die Auswahl einer "aktiven" Zeile erfordern.
• Tabellen werden mit historischen Daten verstopft, die nicht regelmäßig ausgewählt / aufgerufen werden.

Nur die geänderte Spalte temporal speichern.

Halten Sie eine Tabelle bereit, die Änderungen an allen Tabellen verfolgt und notiert, zu welcher Zeile sie gehört und wann sie gültig ist.

Vorteile

• Optimierter Speicher in Bezug auf Revisionen als unveränderte Daten, die nicht repliziert werden.

Nachteile

• Abfragen, die viel komplexer sind, um die Version der Spalte mit den anderen Daten zu kombinieren.

Ich habe mir bereits die folgenden Fragen zu SO und diesen anderen Ressourcen angesehen

Bearbeiten: Der Grund, warum ich diesen Beitrag nicht mit einem bestimmten DBMS markiert habe, da ich möchte, dass das Konzept mit so vielen wie möglich als Plattform funktioniert, ist zur Zeit DBMS-unabhängig und die Abstraktionsschicht erlaubt es zu arbeiten mit MySQL und MSSQL, aber wird hoffentlich andere in der Zukunft unterstützen.

• Datenbankdesign für Revisionen?
• Relationales Schema für Fowlers zeitliche Ausdrücke
• Datenbankdesign für Textüberarbeitungen
• Revisionen relationaler Objekte auf effiziente Weise speichern
• Seitenverlauf wird gespeichert. Ein bisschen wie SO für Revisionen
• Verlauf in einer Datenbank verwalten
• Ссылка
• Ссылка