Ich bin mir nicht sicher, ob es einen "besten Ansatz" gibt, es gibt so viele Variablen, die berücksichtigt werden müssen, einschließlich, wie weit Sie auf dem Entwicklungspfad sind.
Nachdem ich sowohl Code-basierte als auch DB-Trigger-Auditing-Lösungen durchlaufen habe, habe ich unten einige Kommentare aufgelistet; Ich hoffe, Sie können sehen, wo Sie sich jetzt befinden (in Bezug auf die Entwicklung), was sich auf diese Probleme auswirken könnte:
- Wenn Sie den Benutzer zuordnen müssen, der die Daten geändert hat (was Sie normalerweise tun), müssen DB-Trigger diese Informationen irgendwie abrufen. Nicht unmöglich, aber mehr Arbeit und mehrere Möglichkeiten, dies anzugehen (DB-Benutzer, der eine Abfrage ausführt, gemeinsame Benutzerspalte in jeder Tabelle usw.)
- Wenn Sie DB-Trigger verwenden und sich auf die Anzahl der betroffenen Zeilen verlassen, die von Abfragen zurückgegeben wird, muss dies für Ihre Audit-Trigger deaktiviert oder Ihr vorhandener Code geändert werden, um sie zu berücksichtigen.
- IMHO bieten db-Trigger mehr Sicherheit und einen einfacheren Weg zur Audit-Automatisierung, sie sind jedoch nicht narrensicher, da jeder mit entsprechendem Zugriff die Trigger deaktivieren, Daten ändern und sie dann wieder aktivieren kann. Stellen Sie mit anderen Worten sicher, dass Ihre db-Sicherheitszugriffsrechte streng sind.
- Eine einzige Tabelle für den Verlauf zu haben, ist kein schlechter Weg, obwohl Sie mehr Arbeit zu erledigen haben (und Daten zu speichern), wenn Sie den Verlauf für mehrere Tabellen prüfen, insbesondere wenn es darum geht, den Prüfpfad zu rekonstruieren. Sie müssen auch Sperrprobleme berücksichtigen, wenn viele Tabellen versuchen, in eine Audit-Tabelle zu schreiben.
- Eine Audit-Verlaufstabelle für jede Tabelle ist eine weitere Option. Sie müssen nur jede Spalte in der Audit-Tabelle nullfähig machen und Datum und Uhrzeit der Aktion (Einfügen/Aktualisieren/Löschen) sowie den mit der Aktion verknüpften Benutzer speichern.
- Wenn Sie sich für die Option mit einer einzelnen Tabelle entscheiden, sollten Sie nicht zu ausgefallen sein, nur Aktualisierungen oder Löschungen zu prüfen, es sei denn, Sie haben viel Zeit dafür, obwohl es verlockend sein kann, Einfügungen zu vermeiden (da die meisten Apps tun dies häufiger als Aktualisierungen oder Löschungen), erfordert das Rekonstruieren des Prüfverlaufs einiges an Arbeit.
- Wenn sich Ihre Server oder Daten über mehrere Zeitzonen erstrecken, sollten Sie die Verwendung eines geeigneten datetime-Typs in Betracht ziehen, um die Zeitachse speichern und rekonstruieren zu können, d. h. das Datum des Audit-Ereignisses in UTC speichern und den Zeitzonen-Offset einbeziehen.
- Diese Audit-Tabellen können riesig werden, also haben Sie eine Strategie, wenn sie beginnen, die Leistung zu beeinträchtigen. Zu den Optionen gehören Tabellenpartitionierung auf verschiedene Platten, Archivierung usw. Denken Sie grundsätzlich jetzt darüber nach und nicht, wenn es ein Problem wird :)
