Das beste design für ein changelog / Audit-Datenbank-Tabelle?[geschlossen]

https://stackoverflow.com/questions/201527

03-07-2019
|

Frage

Ich brauche zum erstellen einer Datenbank-Tabelle zu speichern verschiedener change-log/Audit (wenn etwas Hinzugefügt wurde, gelöscht, geändert, etc).Ich brauche nicht zu speichern, vor allem detaillierte Informationen, so dass ich dachte, etwas entlang der Linien von:

id (für Veranstaltung)
Benutzer, die es ausgelöst hat
event name
Ereignis-Beschreibung
Datum der Veranstaltung

Bin ich etwas fehlt hier?Natürlich kann ich halten die Verbesserung der design, obwohl ich planen Sie nicht, dass es kompliziert (Erstellung andere Tabellen für die event-Typen und ähnliches ist ausgeschlossen, da es eine Komplikation für mein Bedürfnis).

Lösung

Im Projekt arbeite ich an, Audit-Protokoll auch von dem sehr minimalistischen Design beginnt, wie die, die Sie beschrieben:

event ID
event date/time
event type
user ID
description

Die Idee war das gleiche: die Dinge einfach zu halten.

Es wurde jedoch schnell klar, dass dieses minimalistische Design nicht ausreichend war. Die typische Prüfung wurde Einkochen auf Fragen wie diese:

Who the heck created/updated/deleted a record 
with ID=X in the table Foo and when?

Also, um schnell, solche Fragen beantworten zu können (unter Verwendung von SQL), am Ende haben wir zwei zusätzliche Spalten in der Audit-Tabelle oben mit

object type (or table name)
object ID

Das ist, wenn Design unserer Audit-Log wirklich stabilisiert (für ein paar Jahren).

Natürlich ist die letzte „Verbesserung“ funktionieren würde nur für Tabellen, den Ersatzschlüssel hatte. Aber rate mal was? Alle unsere Tabellen, die Wirtschaftsprüfungs wert sind, haben einen solchen Schlüssel!

Andere Tipps

Es gibt mehrere Dinge, die Sie prüfen möchten, wie Tabelle / Spaltennamen, Computer / Anwendung, aus der ein Update gemacht wurde, und vieles mehr.

Nun hängt es davon ab, wie detailliert Auditierung Sie wirklich brauchen, und auf welcher Ebene.

Wir begannen unsere eigene Trigger-basierter Aufbau Auditing-Lösung, und wir wollten alles prüfen und auch eine Wiederherstellungsoption zur Hand hat. Dies erwies sich als zu komplex sein, so dass wir am Ende umgekehrt den Trigger-based Engineering, Drittanbieter-Tool ApexSQL Audit unsere eigene Lösung zu erstellen.

Tipp:

Fügen Sie vor / nach Werten
3-4 Spalten enthalten für den Primärschlüssel Speicher (falls es ein zusammengesetzter Schlüssel)
Speichern von Daten außerhalb der Hauptdatenbank wie bereits von Robert vorgeschlagen
Machen Sie eine anständige Menge an Zeit auf die Erstellung von Berichten - vor allem diejenigen, die Sie möglicherweise für die Wiederherstellung benötigen
Planen für Host / Anwendungsnamen zu speichern - dies könnte sehr nützlich sein für die Verfolgung von verdächtigen Aktivitäten

Wir protokollieren auch alte und neue Werte und die Spalte sie aus und sind als der Primärschlüssel der Tabelle in einer Audit-Detailtabelle geprüft werden. Denken Sie, was Sie die Audit-Tabelle müssen für? Nicht nur, dass Sie wissen wollen, wer eine Änderung vorgenommen hat und wann, aber wenn eine schlechte Änderung geschieht, möchten Sie einen schnellen Weg, um die Daten zurück zu setzen.

Während Sie entwerfen, sollten Sie den Code schreiben, um Daten wiederherzustellen. Wenn Sie wiederherstellen müssen, ist es in der Regel in Eile ist, am besten schon vorbereitet werden.

Es gibt viele interessante Antworten hier und in ähnlichen Fragen. Die einzigen Dinge, die ich aus eigener Erfahrung hinzufügen kann, sind:

Setzen Sie Ihre Audit-Tabelle in einer anderen Datenbank. Idealerweise sollten Sie die Trennung von den ursprünglichen Daten. Wenn Sie Ihre Datenbank wiederherstellen müssen, wollen Sie nicht wirklich den Audit-Trail wiederherzustellen.
denormalisieren so viel wie vernünftigerweise möglich ist. Sie wollen, dass die Tabelle in die Originaldaten so wenig Abhängigkeiten wie möglich haben. Die Audit-Tabelle sollte einfach und blitzschnell sein, um Abrufen von Daten aus. Keine Lust beitritt oder Lookups über andere Tabellen auf die Daten zu erhalten.

Was haben wir in unserer Tabelle: -

Primary Key
Event type (e.g. "UPDATED", "APPROVED")
Description ("Frisbar was added to blong")
User Id
User Id of second authoriser
Amount
Date/time
Generic Id
Table Name

Die allgemeinen id Punkte in einer Zeile in der Tabelle, die aktualisiert wurde und der Tabellenname ist der Name der Tabelle als String zurück. Kein gutes DB-Design, aber sehr brauchbar. Alle unsere Tabellen haben eine einzige Ersatzschlüssel Spalte so dass diese gut funktionieren.

Es gibt viele Möglichkeiten, dies zu tun. Mein Lieblings-Weg ist:

ein mod_user Feld Ihre Quelltabelle hinzufügen (die, die Sie protokollieren möchten).
Erstellen Sie eine Log-Tabelle, die die Felder enthält, die Sie protokollieren möchten, sowie ein log_datetime und seq_num Feld. seq_num ist der Primärschlüssel.
einen Trigger auf der Quelltabelle aufzubauen, die den aktuellen Datensatz in die Log-Tabelle einfügt, wenn jedes Überwachungsfeld geändert wird.

Jetzt haben Sie eine Aufzeichnung jeder Änderung bekam und wer hat es geschafft.

In der Regel individuelle Prüfung (Erstellung verschiedener Tabellen) ist eine schlechte Option. Datenbank / table-Trigger können deaktiviert werden einige Log-Aktivitäten zu überspringen. Benutzerdefinierte Audit-Tabellen können manipuliert werden. Ausnahmen stattfinden können, die nach unten Anwendung bringen werden. Nicht erwähnt Schwierigkeiten eine robuste Lösung zu entwerfen. Bisher sehe ich eine sehr einfache Fälle in dieser Diskussion. Sie müssen eine vollständige Trennung von der aktuellen Datenbank und von allen berechtigten Benutzern (DBA, Entwickler). All Mainstream-RDBMS bietet Audit Einrichtungen, die selbst DBA nicht in der Lage, manipulations im Geheimen zu deaktivieren. Daher muss zur Verfügung gestellt Audit-Fähigkeit von RDBMS-Anbieter die erste Option sein. Andere Möglichkeit wäre 3rd-Party-Transaktionsprotokollleser oder benutzerdefinierte Protokollleser sein, die Informationen in Nachrichtensystem zerlegt drückt, die in einigen Formen des Audit Data Warehouse oder Echtzeit-Event-Handler endet. Zusammengefasst: Solution Architect / "Hands on Data Architect" muss in Geschick, ein solches System auf Anforderungen basieren einzubeziehen. Es ist in der Regel auch eine ernste Sache nur zur Lösung eines Entwickler zu übergeben.

Nach dem Prinzip der Trennung:

Prüfungsdatentabellen müssen von der Hauptdatenbank getrennt sein. Da Audit-Datenbanken eine Vielzahl von historischen Daten haben können, macht es Sinn, von einem Standpunkt der Speichernutzung, um sich zu trennen.
Sie keine Trigger verwenden, um die gesamte Datenbank zu prüfen, weil Sie mit einem Durcheinander von verschiedenen Datenbanken werden am Ende zu unterstützen. Sie müssen eine für DB2 schreiben, SQLServer, MySQL, etc.

Spät zur party, aber ich empfehle den AutoAudit Projekt.
Es ist 100% kostenlos und open source.Es ist verfasst von SQL MVPs Paul Nielsen und John Sigouin.Es ist sehr stabil und ist derzeit auf version 3.30.

Einfach zu installieren.Führen Sie einfach die SP, die Sie bieten.Es wird ein Audit-Schema, die Wartung von SPs und Trigger muss die überwachung.Von dort aus wählen Sie einfach die Tabellen aus, die Sie möchten zu prüfen und mit welchem detail.

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow