Änderungen mitverfolgen
-
Ich überleg gerade, wie man es am elegantesten löst, wenn man sämtliche Änderungen an einem Datensatz zeitlich zurückverfolgen können will und wollte euch fragen, ob ihr wisst, wie sowas in der Praxis gemacht wird?
Also ob differentiell oder inkrementell, ob alles in einer Tabelle (langsam, aber "sicherer") oder Endergebnis und Historie in getrennten Tabellen (schneller, dafür Gefahr der Dateninkonsistenz), oder auch völlig anders
Danke für eventuelle Denkanstöße
-
meinst du sowas wie undo/redo
-
ich meine eher, einen Datensatz zu jedem beliebigen Zeitpunkt in der Vergangenheit zurückverfolgen zu können. Eine Historie eben
undo/redo könnte man darüber dann auch lösen, ist aber nicht der Grund, warum ich es machen will
-
zwutz schrieb:
ich meine eher, einen Datensatz zu jedem beliebigen Zeitpunkt in der Vergangenheit zurückverfolgen zu können. Eine Historie eben
undo/redo könnte man darüber dann auch lösen, ist aber nicht der Grund, warum ich es machen will
hab mal sowas gemacht, dazu hab ich einfach in einer zweiten tabelle alle INSERT, UPDATE und DELETE statements mit den counterparts gespeichert also so in der richtung
redo undo INSERT DELETE DELETE INSERT UPDATE UPDATEdas problem ist aber um einen bestimmten zustand herzustellen mußte man immer alle querys wieder ausführen.
bin mittlerweile der meinung, das die db soetwas schon mitbringt? das sollte dann schon das schnellste sein
-
ich hatte an sowas gedacht:
inkrementell, alles in einer Tabelle:
id aennr wert1 wert2 wert3 zeit -------------------------------------------------------- 0 0 eins zwei drei 0 0 1 vier NULL NULL 1 0 2 NULL fünf NULL 2 0 3 NULL NULL sechs 3differentiell, alles in einer Tabelle:
id aennr wert1 wert2 wert3 zeit -------------------------------------------------------- 0 0 eins zwei drei 0 0 1 vier NULL NULL 1 0 2 vier fünf NULL 2 0 3 vier fünf sechs 3als Ergebnis jeweils zum Zeitpunkt 3:
id wert1 wert2 wert3 -------------------------------------- 0 vier fünf sechsjetzt besteht natürlich noch die Möglichkeit, das Ergebnis separat abzulegen, was vorteilhaft sein dürfte, wenn man oft den neuesten haben will
aber ok, ich denke, da gibts keine Patentlösung. Ich werd mal die Zwei-Tabellenlösung versuchen... mit Transaktionen sollte ich die Gefahr der Inkonsistenz eigentlich in den Griff bekommen
-
zwutz schrieb:
aber ok, ich denke, da gibts keine Patentlösung. Ich werd mal die Zwei-Tabellenlösung versuchen... mit Transaktionen sollte ich die Gefahr der Inkonsistenz eigentlich in den Griff bekommen
So macht es auch die SAP in ihrer BS1-Lösung. Es gibt die Originaltabelle mit dem aktuellen Datensatz und eine Historientabelle, in der der komplette alte Datensatz noch mal liegt, respektive eine einstellbare Anzahl dieser. Der einzige Unterschied im Tabellenaufbau ist eine mitlaufende ID (jeweils von 1 bis x für die alten Datensätze), so dass man die chronologische Reihenfolge sieht. Wenn der x+1 Historiensatz geschrieben werden soll, wird der älteste Datensatz gelöscht. Das wird dort aber wirklich nur zum Nachsehen angeboten, nicht zum Wiederherstellen.
Gruß KK
-
zwutz schrieb:
differentiell, alles in einer Tabelle:
id aennr wert1 wert2 wert3 zeit -------------------------------------------------------- 0 0 eins zwei drei 0 0 1 vier NULL NULL 1 0 2 vier fünf NULL 2 0 3 vier fünf sechs 3wenn dann würde ich es genau so machen, nur würde ich es nicht "differenziell" nennen. ich verstehe glaube ich wie du auf den namen kommst, aber irgendwie finde ich ihn trotzdem nicht passend.
und auf jeden fall alles in einer tabelle.
wenn irgendwas zu langsam wird, kann man ja - je nach datenbank - einen filtered index oder eine indexed view verwenden, die dann nur die jeweils aktuellen datensätze enthält.wird dadurch nicht wesentlich grösser als die version wo history und current getrennte tables haben, ist schnell abzufragen, und die konsistenz garantiert dir das DBMS.
p.S.: mir fällt gerade auf: ich bin mir gar nicht 100% sicher ob das mit MSSQL (dem einzigen DBMS was ich wirklich gut kenne) mit indexed views und/oder filtered indexes gehen würde...
müsste ich mal ausprobieren...
-
hustbaer schrieb:
wenn dann würde ich es genau so machen, nur würde ich es nicht "differenziell" nennen. ich verstehe glaube ich wie du auf den namen kommst, aber irgendwie finde ich ihn trotzdem nicht passend.
keine Ahnung, wie man es nenn würde, also hab ich es so genannt, wie man es bei Backups nennen würde
Aber danke euch, auf eine View bin ich auch gekommen, so kann ich Geschwindigkeit und Konsistenz denk ich gut unter einem Hut bringen
-
Wieso nennst Du es nicht "Versionierung"? Von jedem Datum wird doch eine neue Version angelegt. aennr entspricht der Version.
-
Welches DBS verwendest du überhaupt?
Ich hatte mal so ein Projekt bei dem in psychatrischen Einrichtungen auftretende Ereignisse gemeldet werden mussten, die Administratoren sollten diese Meldungen aus Datenschutzgründen anpassen können und das Original sollte jedoch erhalten bleiben weil sich der Staatsanwalt dafür mgl. interessierte. Also ein Original mit n Kopien die in einem Selfjoin auf das Original verwiesen. Ich hatte damals mit einem ORM gelöst: die Klassen haben ICloneable implementiert, die letzte Kopie geladen und mit Clone() neue Objekte erzeugt die dann wieder in den Tabellen eingefügt wurden.
Wenn du die Versionshistorie per Hand bauen willst kannst du mal prüfen wie weit du das mit Trigger/Rules automatisieren kannst damit die Fehleranfälligkeit durch das Implementieren im Client wegfällt.
-
witte schrieb:
Welches DBS verwendest du überhaupt?
Noch kein spezielles, zur Auswahl stehen aber MySQL und MSSQL.
Bin noch in der Konzeptphase und bau mir grad ein ERM zusammen, dabei kam mir eben der Gedanke, dass eine Änderungshistorie sinnvoll wäre
-
Für eine PostGreSQL-Datenbank habe ich mal eine Historienverwaltung alleine über Trigger gelöst (die Historientabellen waren getrennte Tabellen und jede Tabelle verfügte über eine Datumsstempel-Spalte 'modified_date').
Es mußte dann in der Anwendungssoftware nichts dafür extra programmiert werden.
Nur der Zugriff auf die archivierten Daten (d.h. anhand eines bestimmten Datums) war eine etwas kompliziertere Stored-Procedure.Da ich mir bei MySQL nicht sicher bin, ob diese schon Trigger unterstützen, würde ich dir dann zu MS-SQL raten (oder aber eben PostGreSQL).
-
Th69 schrieb:
Für eine PostGreSQL-Datenbank habe ich mal eine Historienverwaltung alleine über Trigger gelöst (die Historientabellen waren getrennte Tabellen und jede Tabelle verfügte über eine Datumsstempel-Spalte 'modified_date').
Wieso nimmst du dafür nicht RULES? Ist doch noch einfacher.
-
Das schöne an INSERT-only Lösungen ist doch dass sie INSERT-only sind
D.h. man muss weder DELETE noch UPDATE Rechte vergeben.
D.h. man kann *sicher* sein, dass *nie* alte Daten vernichtet werden, egal was die Anwendung macht.
(Natürlich nur solange man davon ausgeht dass das DBMS keinen Bug hat, aber da mache ich mir weniger Sorgen)Ich finde das immer äusserst beruhigend.
Und natürlich ist es toll für die Beweisbarkeit.
Und es ist eine IMO sehr einfache sowie elegante Lösung.
-
ich bevorzuge die Methode der 2 Tabellen. Die Tabelle mit den original-Datensaetzen und die Historie mit allen Vergangenen, identifiziert durch eine
steigende Versionsnummer. Je nach Struktur sind Trigger durchaus hilfreich.
Kommt halt drauf an, was bei einer Aenderung noch alles gemacht werden soll. Das
reine wegsichern der Datensaetze in eine Historientabelle mit Version und Datum
ist hier aber mit nem Trigger vorzuziehen. Dann vergisst man es wenigstens nicht
Durchaus kann man in die Historientabelle auch noch den aktuellen Datensatz mit auflisten. Gerade wenn man Versionsdatensaetze fuer einen Benutzer zur Uebersicht
anzeigen moechte, spart man sich hier das zusammenfrimeln aus zwei Tabellen.
Geschmackssache.
-
Ich hab sowas auch mit nem Trigger (Postgresql) gelöst.
Hat den Vorteil, daß egal, wie auf die DB zugegriffen wird. Tool,
Konsoleninterface, Anwendung - auf jeden Fall die Historie geschrieben wird.
