Die Lösung von rapante setze ich seit Jahren in verschiedenen Projekten ein - sehr schnell umgesetzt und es ist über die Jahre alles nachvollziehbar. Der Admin (und nur der!) hat Vollzugriff auf die Historie-Tabelle auch vom Programm aus (ok, das ist ein klein wenig Mehraufwand für das zusätzlich Fenster).
Das ist zwar nicht super elegant aber erfüllt seinen Zweck und bei den heutigen
DB's und billigem Plattenplatz kein Problem. Quick aber - wie ich finde - nicht dirty!
Hartmut
Wie elegant willst Du es denn noch haben?
Genauso machen wir das auch. Über History-Tabellen die via Trigger beim Löschen des Datensatzes oder Update eines oder mehrer Felder
(Update = Feldinhaltänderung bzw. neuer Feldinhalt ist leer, alter nicht bzw. alter Feldinhalt ist leer, neuer nicht) befüllt werden.
Die aktuelle Benutzer-ID ist dem Programm bekannt und wird daher in einer PrepareSave Methode dem Datensatz vor dem Abspeichern in die
DB hinzugefügt. Der
SQL-Quelltext für den (die) Trigger wird von der
DB-Klasse (sie kennt ja alle Felder) generiert und beim Überprüfen
des
DB-Schemas bei Programmstart hinzugefügt bzw. geändert, falls Felder hinzugekommen sind.
Das Löschen- bzw. Ändern-Dürfen wird per Benutzer- bzw. Rechteverwaltung gelöst.
Ist meiner Meinung elegant genug.
