C/C++ Forum :: Änderungen mitverfolgen

zwutz Mitglied 20:04:02 04.03.2010 Titel:

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

Unregistrierter

meinst du sowas wie undo/redo :confused:

zwutz Mitglied 21:08:07 04.03.2010 Titel:

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

Unregistrierter

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

Code:
redo undo INSERT DELETE DELETE INSERT UPDATE UPDATE

Code:
redo undo INSERT DELETE DELETE INSERT UPDATE UPDATE

Code:
redo undo INSERT DELETE DELETE INSERT UPDATE UPDATE

das 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 :rolleyes:

zwutz Mitglied 21:27:55 04.03.2010 Titel:

ich hatte an sowas gedacht:

inkrementell, alles in einer Tabelle:

Code:
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 3

Code:
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 3

Code:
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 3

differentiell, alles in einer Tabelle:

Code:
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 3

Code:
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 3

Code:
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 3

als Ergebnis jeweils zum Zeitpunkt 3:

Code:
id wert1 wert2 wert3 -------------------------------------- 0 vier fünf sechs

Code:
id wert1 wert2 wert3 -------------------------------------- 0 vier fünf sechs

Code:
id wert1 wert2 wert3 -------------------------------------- 0 vier fünf sechs

jetzt 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

Killer-Kobold Mitglied 22:19:48 04.03.2010 Titel:

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

hustbaer Mitglied 23:13:16 04.03.2010 Titel:

zwutz schrieb:

differentiell, alles in einer Tabelle:

Code:
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 3

Code:
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 3

Code:
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 3

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.
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...

zwutz Mitglied 07:28:14 05.03.2010 Titel:

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

Marc++us Administrator 07:57:38 05.03.2010 Titel:

Wieso nennst Du es nicht "Versionierung"? Von jedem Datum wird doch eine neue Version angelegt. aennr entspricht der Version.

witte Mitglied 12:58:17 05.03.2010 Titel:

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.