Re: Dokumentation zeitlicher Änderungen: Datenstruktur?



Am Mon, 01 May 2006 17:45:11 +0200 schrieb Paul Schmidinger <my.email.is.on@xxxxxxxxxxxxxxxxxxxx>:

Hallo,


Nun gibt es eine neue Aufgabenstellung: Kennwerte sind ab sofort zeitlich zu
protokollieren. D. h. es muss klar abgelegt werden von wann bis wann welcher
Wert gültig war. Der momentane Ist-Stand soll natürlich möglichst einfach
bestimmbar sein. Und eine halbwegs einfache "Lesbarkeit" der Tabellen wäre
für manuelle Eingriffe auch wünschenswert. Widersprüche und Fehler sollten
möglichst gar nicht "abbildbar" sein.



Ich frage mich nun, was am sinnvollsten ist:


Du möchtest die zeitliche Änderung der Inhalte protokollieren, die Datenstruktur bleibt konstant, oder? Dann würde ich wie folgt vorgehen: jede zu protokollierende Tabelle einfach duplizieren und beim Update und delete den "alten Datenatz" in die Historientabelle kopieren. Das kann man sehr schön mit Triggern lösen, die haben vor allem den Vorteil, dass sie immer protokollieren, egal wer wann was wie ändert. Ausserdem würde ich noch festhalten, wer den Datensatz geändert hat, wann er den Datensatz geändert hat und was passiert ist (Update oder Delete, im Beispiel das "Action"-Feld).

Vorteile dieser Methode:
- die originaltabellen brauchen nicht geändert werden
- Datensatzhistorie einfach über Views abbildbar (z.B. select 'aktuell' Status <felder> from originaltabelle where primärschlüsselfeld=... union all select action,<felder> from historientabelle where primärschlüsselfeld=...
- Trigger und DDL für Historientabelle lassen sich durch geschickte Abfrage des Data-Dictionaries recht elegant generieren

Nachteile:
- die Datenbank wird niemals kleiner, es sei denn du löscht die Historiendaten
- Massenupdates können durch Trigger verlangsamt werden
- du brauchst einen eindeutigen Primärschlüssel je Tabelle, der sich möglichst nicht ändert (was zum Beispiel bei zusammengesetzten PKs aus n:m verbindungen hin und wieder vorkommt) --> eindeutige ID je Datensatz ist optimal
- PKs sollten niemals mehrfach verwendet werden, z.B. wenn nach dem Löschen eines Satzes ein alter PK wieder verwendet wird (irgendwie habe ich im Hinterkopf, dass der SQL-Server das mal gemacht hat)

Die Vorteile (vor allem der lückenlosen protokollierung) wiegen die Nachteile in meinen Anwendungen jedoch in der Regel auf.



Viele Grüße
Ulrik


.



Relevant Pages

  • Re: Updatezeitpunkt von Datensatz in Formular speichern
    ... > ich habe ein Formular mit einem Feld, ... > letzte Zugriff auf einen Datensatz gespeichert werden soll. ... > Private Sub Form_AfterUpdate ... Wenn Du etwas mehr protokollieren willst, dann schau Dir mal auf meiner HP ...
    (microsoft.public.de.access)
  • Re: Bearbeitungs-Datum in Datensatz einfügen
    ... > weiß jemand wie ich in einem Datensatz das Datum der letzten ... Ich habe nur eine Funktion gefunden, die das Datum ... > des Neu-Anlegens des Datensatzes einfügt. ... wenn Du noch etwas mehr protokollieren willst (welches Feld wurde wie ...
    (microsoft.public.de.access)