Nachverfolgen von änderungen in einer SQL server 2005 Datenbank
Ich wurde beauftragt mit der Entwicklung einer Lösung, die verfolgt änderungen an einer Datenbank.
Für updates, die ich brauche, um zu erfassen:
- Datum der Aktualisierung
- alten Wert
- neuen Wert
- betroffene Feld
- person zu tun, ändern
- Datensatz-id
- - Tabelle-Datensatz ist in
Für gelöscht:
- Datum löschen
- person zu tun, löschen
- Die Titel/Beschreibung/id des gelöschten Datensatzes. Die Tabellen bin ich das nachverfolgen von änderungen auf alle haben ein title-oder description-Feld. Ich möchte zu bannen, bevor der Datensatz gelöscht wird.
- - Tabelle-Datensatz wurde in
Für Einsätze:
- Datum einfügen
- person zu tun, ändern
- Datensatz-id
- - Tabelle-Datensatz ist in
Habe ich daran gedacht, ein paar Möglichkeiten, dies zu tun:
- Ich bin mit stored procedures für updates/deletes/inserts. Ich würde eine generische "tracking" Tabelle. Es würde genügend Felder zur Erfassung aller Daten. Ich würde dann fügen Sie eine weitere Zeile in jede gespeicherte Prozedur, um die Wirkung von "Datensatz Einfügen" in der tracking-Tabelle".
- Nachteil: alle updates/deletes/inserts sind alle wirre in der gleichen Tabelle
- viele Felder Genullt,
- wie kann ich verfolgen, batch-updates/deletes/inserts? <---- dies könnte nicht ein Problem sein. Ich habe nicht wirklich eine Sache wie diese in die Anwendung.
- wie kann ich erfassen, dass der Nutzer das update. Die Datenbank sieht nur ein Konto.
- Bearbeiten viel bestehenden code zu Bearbeiten.
- Schließlich konnte ich erstellen Sie einen trigger, der aufgerufen wird, nachdem updates/deletes/inserts. Viele der gleichen Nachteile, wie die erste Lösung, außer: ich hätte zu Bearbeiten, wie viel code. Ich bin mir nicht sicher, wie ich den track updates. Es sieht nicht wie es ist ein Weg, mit Trigger zu sehen, vor kurzem aktualisierten Datensätze.
Ich bin mit asp.net, C#, sql server 2005, iis6, windows 2003. Ich habe kein budget, so traurig es ist, ich kann nichts kaufen, mir damit zu helfen.
Dank für Eure Antworten!
Du musst angemeldet sein, um einen Kommentar abzugeben.
Einen trigger hätte nicht alle Informationen, die Sie brauchen für eine Reihe von Gründen, aber keine Benutzer-id ist die Drahtreifen.
Ich würde sagen du bist auf dem richtigen Weg mit einem gemeinsamen sp einfügen, wo immer eine änderung vorgenommen wird. Wenn Sie die Standardisierung auf sp ' s für die Schnittstellen dann bist du vor dem Spiel - es wird schwer sein, zu schleichen, eine änderung, die nicht nachverfolgt.
Betrachten dies als das äquivalent von ein audit trail in einer accounting-Anwendung - das ist das Journal - eine einzelne Tabelle mit jeder Transaktion aufgezeichnet. Sie wäre nicht umzusetzen, separate Zeitschriften für Einzahlungen, Auszahlungen, Anpassungen, etc. und dies ist das gleiche Prinzip.
Ich hasse zu Seite-Schritt das Problem und ich weiß, Sie haben kein budget, aber die einfachste Lösung ist ein upgrade auf SQL Server 2008. Es hat diese Funktion gebaut in. Ich dachte, das sollte zumindest erwähnt werden, für alle anderen, die auf diese Frage, auch wenn Sie nicht verwenden können, es selbst.
(Unter den einsetzbaren Editionen von SQL 2008 dieses feature ist nur verfügbar in der Enterprise.)
Ich würde vorschlagen, Sie zu nutzen, 2. Spalte ist in jeder Tabelle. Namen rowhistory und IsDeleted und der Datentyp xml und bit.
Nie löschen Sie die Zeilen, immer use-flag IsDeleted
Gehen Sie jetzt mit update-Trigger. Ich geben Sie beispielsweise für die gleiche
Ich habe diese Tabelle genannten Seite
Nun nach dem erstellen der Tabelle alle Sie tun müssen ist, kopieren Sie den code unten, und Ihre Aufgabe ist gemacht für die Seite Tabelle. Es beginnt die Aufzeichnung der Geschichte der Reihe in der gleichen Zeile, die aktualisiert wird, zusammen mit alten und neuen Werten.
Nun, wenn Sie ausführen, aktualisieren Sie Ihre Daten gespeichert werden, rowhistory Spalte
Einer Weise, die ich gesehen habe, behandelt (obwohl ich würde es nicht empfehlen, ehrlich gesagt) ist es zu handhaben über gespeicherte Prozeduren, vorbei an der userid/username/was auch immer als parameter. Die gespeicherte Prozeduren aufrufen würde ein logging-Verfahren, das schrieb die relevanten details in einer zentralen log-Tabelle.
Hier, wo es ein wenig schrill, obwohl...
Für INSERTs/UPDATEs, die relevanten Zeile(N) wurden in der Tabelle gespeichert wie die XML-Daten nach dem EINFÜGEN/AKTUALISIERUNG erfolgreich abgeschlossen wurde. Für Löscht die Zeile gespeichert wurde, die vor dem LÖSCHEN ausgeführt (obwohl, realistisch gesehen, Sie hätte es von der DELETE-Anweisung die Ausgabe-zumindest mit SQL Server 2005).
Wenn ich mich richtig erinnere, die Tabelle hatte nur ein paar Spalten: UserID, DateTime des logging -, Transaktions-Typ (I/U/D), XML-Daten mit den relevanten Zeilen, Tabellenname und der Primärschlüssel-Wert (hauptsächlich für die schnelle Suche, was die Akten, die Sie wollten).
Viele Möglichkeiten, um der Haut eine Katze, obwohl...
Mein Rat ist, zu halten ist einfach. Erweitern Sie es später, wenn Sie müssen.
Wenn Sie haben die Fähigkeit, dies zu tun, sperren Sie die Benutzer nur in der Lage sein zu führen verwertbare Aussagen auf Tabellen über gespeicherte Prozeduren und dann mit der Protokollierung (wie Sie wollen) von dort.
Bauten wir unsere eigene und brauchte nur die Benutzer-und pc an jedem add/update gespeicherte Prozedur. dann ist es nur eine Frage der ursprünglichen Datensatz und dem füllen der Variablen und der Vergleich mit den übergebenen Variablen und Protokollierung der Daten an unseren Tisch.
für gelöscht, wir haben nur eine Kopie des ursprünglichen Tabellen + ein timestamp-Feld, so wird der Datensatz nie wirklich gelöscht und können jederzeit wiederhergestellt werden, die wir brauchen (offensichtlich ist der löschen-routine prüft für FK-Beziehungen und so).
hinzufügen/update-log-Tabelle aussieht
datetime,
table_name,
column_name,
record_id,
old_value,
neuer_wert,
user_id,
computer
wir nie einfügen von Nullen, so dass wir Sie zu konvertieren leeren Saiten, neue Einträge sind markiert mit '{neuer Eintrag}' in der old_value Spalte. record_id aus, wie viele Schlüssel-Spalten zur eindeutigen Identifizierung einzelner Datensatz ( Feld1 + '.' + Feld2 + ... )
Zunächst einmal, in aller Ihrer Tabellen sollten Sie mindestens die folgenden Spalten Hinzugefügt, um die Daten Spalten DateCreated, UserCreated, DateModified, UserModified. Möglicherweise möchten Sie vielleicht ein "Status" oder "LastAction" - Spalte, so dass Sie nicht immer tatsächlich eine Zeile zu löschen, die Sie gerade legen Sie es auf einen gelöschten/eingefügten/aktualisierten status. Als Nächstes könnte eine "Historie Tabelle", die eine exakte Kopie der ersten Tabelle. Dann auf Aktualisierungen oder löscht die trigger kopieren Sie die Tabelle Gelöscht, Einträge in die History-Tabelle die änderung der DateModified, UserModified und Status Felder in der gleichen Zeit.
Hatte, habe ich ein setup in SQL Server wo wir verwenden würden, Ansichten für den Zugriff auf unsere Daten, die behandeln würde, Einfügungen, Aktualisierungen und Löschungen mit INSTEAD OF-Triggern.
Beispiel: ein STATT LÖSCHEN - trigger für die Sicht würde markieren Sie die Datensätze in der zugrunde liegenden Tabelle als gelöscht, und die Ansicht gefiltert wurde, um nicht gelöschte Datensätze.
In allen auslöst, die wir aktualisiert das änderungsdatum und Benutzername. Das Problem ist, dass logs der Datenbank-Benutzer-Namen, das ist nicht das gleiche wie die ultimative Anwendung, die Benutzer-Namen.
Ansicht muss an ein schema gebunden sein, für diese zu arbeiten.
Zur Erfassung der Benutzer, dass änderungen der DB: Sie können beliebig viele SQL-Benutzer, wie Sie für die DB und wenn du sessions verwenden und beschränkt/registrierten Zugang zu Ihrem Programm/Skript
Sie können diese Informationen verwenden, um einzuleiten verschiedenen DB-Verbindungs-Einstellungen (z.B. username),
vor einer operation mit der DB.
Zumindest das sollte machbar sein für PHP-klug-Skripts, aber ich könnte falsch sein für asp.net.