Ä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 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 🙄



  • 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     3
    

    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     3
    

    als Ergebnis jeweils zum Zeitpunkt 3:

    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



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



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


Log in to reply