Historie Funktion für Datenbanken

[punkrandy]

Hallo Leute,

ich habe eine Frage zum Thema Historie in einer Datenbank und zwar schon mal ganz grob: Wie realisiert man soetwas? (Best practices etc.)

Gemeint sind im Prinzip für zwei Anwendungsfälle.
Stammdaten: Hier soll die Änderung und durch welchen Benutzer diese durchgeführt wurde vollkommen transpart nachträglich nachvollziehbar sein, so dass auch bestimmte Eigenschaften Rückwirkend mit dem aktuellen Wert an einem entsprechenden Datum ausgewertet werden können (Beispiel: Anzahl Mitarbeiter eines Kunden - Dieser kann variieren aber es muss nachvollziehbar sein, wieviele Mitarbeiter eine Firma zu welcher Zeit gehabt hat)

Operative Daten: z.B. für Bestellungen soll es möglich sein diese Nachträglich zu verändern, der vorherige Werte sollte aber in einer Historie im System abfragbar sein, so dass man Änderungen nachträglich genau bestimmen kann zu Statistiken zwecken etc.

Im Endeffekt geht es um eine lückenlose statistische Transparenz.

Sollte sowas in der Datenbank über Trigger/Stored Procedures erledigt werden oder denkt ihr das ist Aufgabe der darauf zugreifenden Applikation. Ich wäre über jede Erfahrung mit diesen Thema "History" dankbar.

Vielen Dank

[Christian Marquardt]

Sollte sowas in der Datenbank über Trigger/Stored Procedures erledigt werden oder denkt ihr das ist Aufgabe der darauf zugreifenden Applikation.

Darüber kann man stundenlang diskutieren....

Letzlich sollte es sich in das Konzept der Anwendung und der DB einpassen.

Ist es eine Anwendung mit einer DB?
Performance bei Realisierung in DB und außerhalb?
Ist jetzt schon alles soweit möglich in der DB realisiert?

....

[dimitri]

Hi,

es gibt grundsätzlich mal zwei Möglichkeiten. Zum einen die schon von dir angesprochene Möglichkeit mittels Triggern die Änderungen in entsprechende Historisierungstabellen zu schreiben und dabei z.B: mit einem Timestamp und Transaktionsnummer etc. anzureichern.
Wir machen das bei uns so. dabei werden die Trigger über velocity templetes dynamisch generiert und müssen nicht etwa selbst geschrieben werden.
Dieses verfahren würd ich aber nicht als wasserdicht bezeichnen.

Wenn ihr SOX konform oder ähnliche Anforderungen eurer Revision erfüllen müsst, werdet ihr damit evtl. Probleme haben, denn einen Trigger kann man auch ganz einfach mal ausschalten bzw. diese laufen unter dem SYS user auch gar nicht.
Hier bieten Datenbanken selbst eine Audit Funktion an. In Oracle z.B. Fine Grained Auditing mit dem alle DMLs/DDLs und sonstigen Veränderungen festgehalten werden können.

Allerdings hat man dann zwar die SQLs zur Verfügung und weiß wer was wann gemacht hat, nicht aber den ursprünglichen Datenstand.

Daher würde also eher der erste Vorschlag in Frage kommen. Dürfte aber nicht mal eben so herunterprogrammiert sein, denn Du willst ja nicht nur einfach einzelne Sätze haben, sondern die komplette Anwendung soll auf den (konsistenten) historisierten Daten arbeiten können.

Dazu gehört auf jeden fall eine Zugriffsschicht, die damit umgehen kann und die Zugriffe entsprechen umleitet. Das erfordert bei einem umfangreichen ER-Modell schon einiges an Aufwand und viel Planung.

Dim