Wir implementieren ein neues System mit Java/Spring/Hibernate für PostgreSQL. Dieses System muss eine Kopie von jedem Datensatz erstellen, sobald eine Änderung/Löschung an den Datensätzen in den Tabellen vorgenommen wird. Später werden die Audit-Tabelle (n) von Reports abgefragt, um die Daten den Benutzern anzuzeigen.Implementierung der Überwachung/Versionierung von Tabellenänderungen in PostgreSQL
Ich habe geplant, diese Auditing/Versionierungsfunktion durch einen Trigger für die Tabelle (n) zu implementieren, die eine Kopie der geänderten Zeile (gelöschte Zeile) "TO" eine Tabelle mit dem Namen ENTITY_VERSIONS machen würde, die etwa 20 Spalten hätte col1, col2, col3, col4 usw. genannt, die die Spalten aus der obigen Tabelle (n) speichern würden; Das Problem ist jedoch, dass, wenn es mehr als 1 zu versionierende Tabelle und NUR 1 TARGET-Tabelle (ENTITY_VERSIONS) gibt, um alle Tabellenversionen zu speichern, wie entwerfe ich die TARGET-Tabelle?
ODER ist es besser, dass es für jede Tabelle, die eine Versionierung benötigt, eine KOPIE der VERSION Tabelle gibt?
Es wird von Vorteil sein, wenn einige Hinweise auf PostgreSQL-Trigger (und zugehörige Stored Procedures) zur Implementierung der Auditing/Versionierung freigegeben werden können.
P.S: Ich schaute auf Suggestions for implementing audit tables in SQL Server? und ein bisschen wie die Antwort, außer ich würde nicht wissen, welcher Typ sollte OldValue und NewValue sein?
P.P.S: Wenn die Tabellen SOFT DELETEs (Phantom Deletes) anstelle von HARD Deletes verwenden, ändern sich Ihre Ratschläge?
+1 danke. Ich frage mich, was die Stärken einer "GLOBAL Audit TABLE" vs "Audit-Tabelle für jede Tabelle" sind wr.t Abfrage der Daten für die Berichterstattung? – anjanb
Wenn Sie es irgendwie schaffen, eine GLOBAL-Audit-Tabelle zu haben, sehe ich ALOT von Typ Casting. Ich meine ... in welcher Art würden Sie alle Spalten speichern? – rfusca
rfusca: richtig. ja, das waren auch meine Zweifel! – anjanb