Historie mit Trigger?

[Undeathly_Shadow]

Hallo,

ich habe eine DB zu erstellen welche mehrere Tabellen enthält.
Ich soll ausserdem ein jeder Tabelle überwachen:
WER, WANN, WAS
gemacht hat, dies betrifft natürlich nur Änderungen wie
Insert Update und Delete

Meine Idee war nun ein (mehrere) Trigger welche(r) mir in eine seperate Tabelle
alle betreffenden Angaben speichert. Vorgestellt hab ich mir das ungefähr so:

Tabell:

Tbl_ID(int, Identity)
DBID (int)
OldValue (varchar(180))
NewValue (varchar(180))
DateStamp (DateTime)
UserID (varchar(9))
TableName (varchar(25)

Macht das so Sinn?
Bessere Ideen?
kann ich in ein Varchar auch Datetimewerte ablegen? (für den Fall ddas ein Datum geändert wir)

Wie schreibe ich so einen Trigger? kann ich den auch gleich auf mehrere Tabellen adressieren?

[Bernhard Geyer]

Bessere Idee: Kauf dir ein fertiges Tool das genau das macht. Ist im Endeffekt günstiger als hier Aufwändig selbst sowas zu implementieren.

[tinof]

@Bernhard,

kannst du da etwas konkretes für den MSSQLServer (2005!) benennen?

Danke
Tino

[hwoess]

Eine einfache Variante ist es in einem INSERT-UPDATE-DELETE-Trigger die Werte aus inserted und deleted recordweise als XML auszulesen und diese als varchar(MAX) abzuspeichern. Dann braucht man sich keine Gedanken über die einzelnen Felder machen. Klar kann man jetzt mit Platzbedarf argumentieren, aber Plattenplatz ist billig und man kann diese Logdaten ja zB jede Nacht in ein Datenfile auf eine nicht so performante dafür aber günstige Platte auslagern.
Beim User, der die Änderungen macht ist es schon schwieriger, wenn nicht mit Windows-Authentifizierung gearbeitet wird oder jeder sich mit seinem eigenen Login anmeldet, da gibt es nämlich Programme, die intern einen allgemeinen SQL-User verwenden, da kann man dann ohne Unterstützung durch die Applikation nicht herausfinden, wer die agierende Person ist. Habe sowas in der Art voriges Jahr realisiert, da liefert die App den Windows-User als Application-Name im Connection-String mit und den kann man per APP_NAME() später im trigger auslesen, damit geht's dann auch.

bye,
Helmut

[edit] ansonsten könntest du dir auch den hier mal ansehen: LogManager

[dimitri]

Hi,

wir haben etwas ähnliches im Einsatz. Während des Buildprozesses werden anhand der Bestandstabellen Historientabellen sowie die dazugehörigen Trigger generiert.

Das ist genau dass, was Du haben möchtest. also investier etwas Zeit in ein kleines Programm, welches die die benötigten Skripte generiert und fertig.

Dim

[tinof]

Danke für die Antworten!

Ich hatte ja hier schon einmal über die xml - Lösung nachgedacht.
Bisher konnte ich den Ansatz aber nicht weiterverfolgen. Ich möchte halt nicht jedes mal den ganzen Satz wegschreiben, sondern nur die Änderungen protokollieren.
Da es aber gerade wieder akut wird muss ich nochmal darüber nachdenken.

Aber auch ein automatisiertes Anpassen von "Mutationstabellen" (@dimitri) ist eine gute Idee! Bei händischer Pflege eines solchen Systems weiß ich nämlich, dass ich dabei regelmäßig etwas übersehen würde. Performancetechnisch wäre solch ein 'einfacher' Trigger sicher auch besser.

Ein Dauerbrenner ...

Danke, schöne Woche
Tino

[Undeathly_Shadow]

Beim User, der die Änderungen macht ist es schon schwieriger, wenn nicht mit Windows-Authentifizierung gearbeitet wird oder jeder sich mit seinem eigenen Login anmeldet, da gibt es nämlich Programme, die intern einen allgemeinen SQL-User verwenden, da kann man dann ohne Unterstützung durch die Applikation nicht herausfinden, wer die agierende Person ist. Habe sowas in der Art voriges Jahr realisiert, da liefert die App den Windows-User als Application-Name im Connection-String mit und den kann man per APP_NAME() später im trigger auslesen, damit geht's dann auch.

bye,
Helmut

[edit] ansonsten könntest du dir auch den hier mal ansehen: LogManager

Hallo Helmut,

vielen Dank für die Ausführungen,
kannst du mir kurz einen Tipp geben wie ich den User im Conn mitgebe?
Den App_Name sehe ich ja noch.

@TinoF:
Da du ja schon mehr Erfahrungen hast, hast du deinen Trigger je Tabelle oder kann man den auch führ mehrere Tabellen machen?

DANKE und Gruß

André

[hwoess]

Wie du den Namen kriegst weißt du wohl schon (sonst einfach nach verwendeter Programmiersprache und Get Windows User googeln).
Und wenn man weiter zB. nach "sql server connection string" googelt, stösst man unter anderem auf diesen Link, da steht's beschrieben...

Wegen dem Trigger: man kann nicht einen Trigger für mehrere Tabellen nutzen aber es ist schon viel einfacher, wenn man je zu überwachender Tabelle einen Trigger anlegt, in dem die Statements immer gleich sind: nur den Tabellennamen und die Daten aus inserted und deleted als XML-String an eine Prozedur übergeben - und die macht dann den Rest. So hat man das eigentliche Handling an einer einzigen Stelle.

bye,
Helmut