Speichern von Änderungen an Aufzeichnungen

Question

Alles, worüber ich spreche, bezieht sich auf die relationale Datenbank, bestimmte MySQL.

Ich habe eine Reihe von Tabellen in einer Datenbank und für eine moderate Anzahl von ihnen möchte ich einen Historie der Datensätzewerte speichern, wenn sie sich ändert. Ich habe das auf verschiedene Arten gesehen:

1. Eine Tabelle/ein Feld - Grundsätzlich gibt es eine Tabelle, die den Verlauf der gesamten Tabelle speichert, die einen Verlaufspeicher benötigt. Alle Änderungen werden in einem Feld als Textdatentyp aufgezeichnet.
2. Tabelle pro Tabelle/ein Feld - wie oben, außer der einzelnen Tabelle verfügt über eine eigene Verlaufstabelle (dh Projekte/Projektlagen, Probleme/Ausgabenhistory usw.).
3. Tabelle pro Tabelle/Feld pro Feld - Dies ist wie die oben genannten in jeder Tabelle. Es hat eine eigene Histroy -Tabelle, aber auch die Tabelle der Geschichte hat die gleiche Definition wie die reguläre Tabelle mit zusätzlichen zusätzlichen historischen Feldern (aktualisiert, aktualisiertUlerid, etc...).

Was sind einige der Vor- und Nachteile dieser verschiedenen Methoden zur Speicherung von Rekordgeschichte? Gibt es andere Methoden, an die ich nicht gedacht habe?

Answer 1

Da Sie viele Tabellen mit unterschiedlichen Spalten haben, wäre Nr. 1 aus, da Sie eine massive Tabelle mit dem Gesamtpunkt aller Spalten und vielen Nulls haben würden.

Zwischen #2 & #3 denke ich, dass Sie eine Entscheidung bezüglich der Designkomplexität treffen können, die Sie verwalten möchten. Ich bin der Ansicht, dass es einfacher wäre, eine genaue Archivreplik für eine bestimmte Tabelle zu verwalten und den gesamten Rowstate (mit modifizierter Zeit) zu speichern. Denken Sie an einen Fall, in dem Sie mehr als eine Spalte einer Zeile aktualisieren. In diesem Fall würde Nr. 2 einen Eintrag für die Änderung der Spalten getrennt protokollieren, obwohl es dieselbe Transaktion war. Ich würde mit W #3 gehen, um die Komplexität zu reduzieren und den Zeitzeilungsstatus zu erfassen.

Answer 2

Sie möchten wirklich zuerst lesen:

http://www.cs.arizona.edu/~rts/tdbbook.pdf

Wenn Sie Ihre Geschichte in einer separaten Tabelle behalten möchten (und wahrscheinlich), möchten Sie wahrscheinlich Option 3; Es ist tendenziell umwerfend und bequemer, #1 sind #2 sind ziemlich hässlich und "nicht relational".

Answer 3

In gewissem Maße hängt es davon ab, wie Sie diese Daten verwenden möchten. Wenn es sich um eine Audit -Tabelle handelt, die ausschließlich in der Lage ist, gelegentlich zu recherchieren, wer was und wann geändert hat, und gelegentlich schlechte Änderungen wiederherstellen, dann ist Option 2 in Ordnung. Wenn Sie beabsichtigen, den Benutzerverlauf der Anwendung oder durch Berichterstattung anzuzeigen, verwenden Sie Option 3. Ich kann mir keinen Umstand vorstellen, an dem ich Option eins verwenden würde, da es sich um einen Orte handelt, an dem das Blockieren stattfindet.