Datenbank Historisierung

[Stefan87]

Hallo Leute,

ich bräuchte mal etwas Hilfe beim Thema Historisierung von DBs.

Welche Methoden kennt ihr und gibt es zu diesem Speziellen Thema vielleicht sogar Bücher?

Bis jetzt bin ich auf diese beiden Methoden gestoßen:

1: Ein Änderungskennzeichen bzw. Validation-Attribut in die Tabelle aufnehmen wo man sehen kann ob der Datensatz gültig ist oder nicht.

2: Eine neue Tabelle erstellen in der die Änderungen Dokumentiert werden Sprich (Änderungsdatum, Person, geänderte Tabelle, geänderte Spalte, neuer Wert, alter Wert usw... ) was man halt so haben möchte.... Diese füllt man dann meist über Trigger die auf die Tabelle gelegt werden für die eine Historie erstellt werden soll.

ich hoffe ihr könnt mir helfen ;-)

[Sacaldur]

den 1. Punkt verstehe ich nicht

was hat eine Validierung mit einer Versionierung (bzw. Archivierung alter Zustände) zu tun?

der 2. Punkt ist eine Möglichkeit, die dir wohl auch am ehesten empfohlen werden dürfte

eien andere Möglichkeit wäre es, in jeder Tabelle ein weiteres Feld mit einem Datum einzufügen, welches das Datum der Erstellung des Datensatzes beinhaltet

jedes Mal, wenn ein Datensatz verändert werden soll, wird ei neuer Datensatz mit den neuen Werten eingefügt

allerdings schafft man sich damit weit mehr Probleme, als mit dem, was du schon geschrieben hast

man muss das bei jeder Tabelle machen, bei der eine Historie geführt werden soll

das Datumsfeld muss zum Primärschlüssel dazu gehören

jede Tabelle, die sich auf diese Tabelle beziehen will, braucht deswegen einen Mehrspaltigen Fremdschlüssel (geht das überhaupt? ^^)

wenn sich dafür kein Trigger erstellen lässt, muss die Geschäftslogik (also das verwendende Programm) aufpassen, dass nicht versehentlich ältere Datensätze überschrieben werden

Tabellen mit entsprechenden Fremdschlüsseln müssten bei neuen Datensätzen aktualisiert werden

ich habe keine Ahnung, wie man Datensätze löschen und die Historie behalten will

...

vergiss einfach diese Idee... x)

bei dem Trigger kannst du zur Optimierung darauf verzischten, den neuen Wert zu speichern, da dieser ja in der Tabelle selbst oder in einem neuerem Logdatensatz voprhanden ist (beim Anlegen kann man auch auf "den alten" Wert verzichten, da es vorher keinen Wert gab)

du müsstest auch festhalten, welche Art von Änderung vorgenommen wurde (INSERT, UPDATE, DELETE und "Rollback", sofern du das in deiner Datenbank anhand der Historie machen lassen willst)

und du musst darauf aufpassen, dass dieser Trigger nur solche Tabellen überwacht, die er überwachen soll (nicht nur unwichtige Tabellen sollen ausgelassen werden, sondern vor allem zwangsweise die Historietabelle, da sonst der Trigger sich immer wieder selbst auslöst)

je nachdem, was du genau vor hast zu speichern, gibt es eventuell noch eine andere Möglichkeit (dazu müsstest du schreiben, was gespeichert werden soll und ggf. auch, warum dafür eine Historie notwendig ist)

[Stefan87]

Unter 1 Meinte ich das man in der Tabelle z.B. ein Feld "Gültig ab" einbaut.... also genau das wie du es beschrieben hast.

Man könnte dann im Programm mit einem View arbeiten der nur die momentan Gültigen Datensätze liefert.

Meine Aufabe ist es mehrer verschiedene Varianten aufzuführen und diese miteinander zu Vergleichen, deswegen bin ich auch für Ideen zu haben die vielleicht nicht die besten wären.

[Sacaldur]

neben einer DB-basierten Logführung kann man auch eine Logdatei im Dateisystem verwenden

diese könnte auf einem anderen Datenträger als die Datenbank selbst liegen und würde dadurch bei verwendung eines RAIDs oder ähnlichem anders gehandhabt werden (so zum Beispiel könnte für die Datenbank selbst etwas weniger, besser gesicherter und evtl. beschleunigter Speicher verwendet werden, während für die Historie eine einfachere und langsamere Variante verwendet wird)

sofern sich dies in irgendeiner Weise über die Datenbank selbst realisieren lässt, sodass die verwendenden Programme davon nichts mitbekommen und sich nicht darum kümmern müssen, wäre das bei einer hohen Belastung der Datenbank durchaus ein Gedanke, den man weiter verfolgen kann

vielleicht fällt mir demnächst noch das ein oder andere ein...

eigentlich könntest du das, was ich im letzten Beitrag schon geschrieben habe (über den 1. Punkt) verwenden

[Stefan87]

Ja das hört sich schonmal gut an.

Und es scheint auch so als wenn zu dem Thema nicht viele eine Meinung hätten... leider ;-)

Falls dir noch eine Idee kommt wäre das super denn ich bin mir sicher das es da noch einige andere Wege gibt.

Aber erstmal vielen Dank das wenigstens Du geantwortet hast

[Sacaldur]

mir ist zwar noch keine weitere Möglichkeit eingefallen, aber dafür noch ein paar Probleme im Zusammenhang mit der Logdatei:

sollten Änderungen rückgängig gemacht werden, dann ist das auch schwieriger zu bewerkstelligen

das Abfragen alter Zustände ist auch nicht (oder schwer) über die Datenbank selbst möglich -> man müsste wohl auf die Datei selbst zugreifen

bei mehreren Benutzern, die gleichzeitig mit der Datenbank arbeiten, kann es zu Problemen kommen, wenn mehrere Benutzer gleichzeitig Daten ändern und somit mehrfach gleichzeitig auf die Datei zugegriffen werden muss (das Problem dabei ist, dass diese Zugriffe nacheinander abgearbeitet werden müssten und dadurch Performance verloren gehen kann - bei Lesezugriffen auf aktuelle Daten wirkt sich das aber nicht negativ aus)

zusammengefasst scheint sich etwas derartiges dann wirklich zu lohnen, wenn man mit unmengen an Daten arbeitet (im Millionenbereich und darüber, sage ich einfach mal), die aber relativ selten verändert, sondern häufig nur gelesen werden

eine Kombination aus den beiden Dinge wäre eine separate Datenbank für die Historisierung (sie könnte aber dennoch vom gleichen DBMS verwaltet werden)

vorteile bringt das, wenn diese an einem anderem Ort liegt (wieder die Vorteile wie bei der Datei)

da man immernoch auf eine Datenbank zugreift, wäre das zurückspielen von alten Zuständen einfacher (denke ich mir zumindest)

im Gegensatz zur Logdatei können die Zugriffsberechtigungen über das DBMS verwaltet werden

eventuell bieten auch die Datenbankmanagementsysteme selbst die Möglichkeit, Änderungen an Datensätzen automatisch zu protokollieren

dies wäre grundsätzlich eine besser Lösung, als selbst etwas zu basteln, da das DBMS diese schon ausreichend lange enthalten dürfte und dem entsprechend diese bereits funktionierend implementiert sind (und man nichts selbst implementieren muss)

allerdings muss man erst einmal ein DBMS haben, welches das unterstützt und diese Funktion könnte eventuell mehr Geld kosten (zumindest bei DBMSs, die grundsätzlich Geld kosten, wie das von Oracle)

ansonsten hat es sehr viele Gemeinsamkeiten mit der separaten Logdatei

[streffin]

Bei dem Thema ist es seeehr relevant was da an DBMS läuft.

Und zwar im Detail. Die teuren Lizenzen haben da zum Teil seehr nette Funktionen, was die (immer noch schweineteurern) billigeren Lizenzen nicht bieten.

die recht triviale Möglichkeit per Trigger Updates wegzuschreiben ist halt leider auch recht unperformat wenn da viel auf der DB gemacht wird.

Gruß

Sven

[.NETter]

Hallo,

ich stimme hier der Lösung des Markierens zu. Ein Datensatz wird mit einem "Gültig von" und einem "Gültig bis" versehen.

So ist es möglich Informationen zu einem bestimmten Zeitpunkt abzurufen.

Das ganze hat auch einen Namen:

Slowly Changing Dimensions

[Guybrush Threepwood]

Hallo,

ich stimme hier der Lösung des Markierens zu. Ein Datensatz wird mit einem "Gültig von" und einem "Gültig bis" versehen.

So ist es möglich Informationen zu einem bestimmten Zeitpunkt abzurufen.

Das ganze hat auch einen Namen:

Slowly Changing Dimensions

Das kommt drauf an wofür du das brauchst.

Wenn du im Programm wissen musst welcher Datensatz zu einem bestimmten Zeitraum gültig ist dann ist das der bessere Weg, wenn du aber einfach nur eine Änderungshistorie brauchst um nachvollziehen zu können wann (wer) etwas geändert hat ist der Weg über eine weitere (Trigger gefüllte) Tabelle besser, da sich an deiner Programmlogik nichts ändert.

[Pixie]

Was soll denn primär der Sinn und Zweck sein? Nachvollziehbarkeit (wer hat wann was geändert) oder Wiederherstellbarkeit an jeden gewünschten Zeitpunkt?

[Sacaldur]

Was soll denn primär der Sinn und Zweck sein? Nachvollziehbarkeit (wer hat wann was geändert) oder Wiederherstellbarkeit an jeden gewünschten Zeitpunkt?

Meine Aufabe ist es mehrer verschiedene Varianten aufzuführen und diese miteinander zu Vergleichen, deswegen bin ich auch für Ideen zu haben die vielleicht nicht die besten wären.

er sucht nicht nach einer für sein Problem passenden Möglichkeit, sondern nach allen, da er als Aufgabe scheinbar nicht das umsetzen einer solchen Lösung hat

[Pixie]

ja schon aber... man macht sowas ja nicht als Arbeitsbeschaffungsmassnahme, sondern, weil etwas damit erreicht werden soll. Und je nach Zielsetzung gibt es nicht nur verschieden gut geeignete Möglichkeiten, sondern auch solche, die generell tauglich oder generell ungeeignet sind.

Oder ist das ganze wirklich nur ein "womit halten wir uns den Azubi vom Hals"-Projekt?

[Stefan87]

So bin auch wieder aus dem Urlaub da. ;-)

Und ja ich soll hier nur die Möglichkeiten aufzeigen und miteinander Vergleichen.

Dabei kommt es mir in erster Linie nicht drauf an was wofür gut ist sondern einfach welche Verfahren es gibt.

z.B. wusste ich nicht das es "Slowly Changimg Dimensions" als Festen begriff dafür gibt.

Also falls ihr für die anderen Verfahren auch Feste begriffe hättet oder auch noch weitere wäre das super.