Audit-Protokollierungsstrategien

Question

Ich versuche, über die beste Methode für die Protokollierung von Protokollen innerhalb meiner Anwendung zu entscheiden. Der Hauptgrund für das Protokoll ist die Meldung der Reihenfolge der Ereignisse (Änderungen).

Ich habe eine Hierarchie von Objekten, ich muss Berichte erstellen, wenn sich etwas an irgendeinem Teil dieser Hierarchie zu einem späteren Zeitpunkt ändert.

Ich denke, dass ich drei Möglichkeiten:

1. haben ein Protokoll für jede Tabelle und damit die Hierarchie von Objekten passende dann eine Ansicht für den Bericht zu erstellen.
2. Reduzieren Sie die Hierarchie und de-normalisieren Sie die Tabelle, um die Berichterstellung zu vereinfachen - einfache Select-Anweisung.
3. Verfügen Sie über eine Protokolltabelle und haben Sie eine Aufzeichnung für jede Änderung, die die Berichterstellung erschwert, aber flexibler für Änderungen macht.

Ich bin derzeit Neigung zu Option 1.

Answer 1

ein Audit-Log ist im Grunde eine chronologische Liste der Ereignisse, die aufgetreten sind, die diese Ereignisse durchgeführt wird, und dem, was die Ereignisse waren.

Ich denke, eine flache Ansicht wäre besser, da es leicht bestellt und abgefragt werden kann. Also lehne ich mich eher Ihrer Option # 2/# 3 zu.

Fügen Sie Dinge wie den Transaktionstyp, die Uhrzeit, die Benutzer-ID, eine Beschreibung der Änderungen und andere relevante Informationen zu Ihrem Produkt ein.

Sie können Ihrem Produkt auch im Laufe der Zeit Dinge hinzufügen, und Sie müssen Ihr Prüfprotokollmodul nicht ständig ändern.

Answer 2

Wenn es für Überwachungszwecke ist, würde ich ein echtes Append-only-Medium anstelle einer Tabelle/Tabellen in der gleichen Datenbank verwenden.

Sie schlagen vor, es ist für Change-History-Zwecke - in diesem Fall würde ich Ihre Anwendung/db restrukturieren, um die tatsächlichen Ereignisse an erster Stelle statt nur den aktuellen Status aufzeichnen.

Answer 3

Ich würde mit (2) und (3) gehen: Erstellen Sie eine einzige Tabelle für alle Audit-Einträge.

Eine flache Ansicht ist gut, vorausgesetzt, die zusätzliche Abflachung wirkt sich nicht auf die Leistung aus.

Answer 4

Sie könnten in ein AOP-Framework schauen, um dabei zu helfen. Damit können Sie die Protokollierungsfunktion am Anfang oder am Ende jeder/aller Methoden einfügen. Wenn Sie diesen Weg gehen, kann es hilfreich sein zu definieren, was sinnvoll wäre, um die Protokolldaten zu speichern.

Answer 5

Ich muss mit diesem Thema sprechen, obwohl es alt ist.

Es ist normalerweise eine schlechte Idee, nur eine Audit-Tabelle zu haben, da Sie Sperrprobleme in der Datenbank erzeugen werden, da alles auf diese Tabelle trifft. Verwenden Sie für jede Tabelle separate Audit-Tabellen.

Es ist auch eine schlechte Idee, dass die Anwendung das Auditing durchführt. Die Prüfung muss auf Datenbankebene erfolgen oder Sie riskieren den Verlust einiger Informationen. Daten ändern sich nicht nur von Anwendungen in den meisten Datenbanken; Niemand wird die Preise aller ihrer Produkte einzeln von der Benutzeroberfläche aus ändern, wenn Sie eine 10% ige Erhöhung auf alle 10.000.000 von ihnen benötigen. Auditing sollte alle Änderungen erfassen, nicht nur einige von ihnen. Dies sollte in den meisten Datenbanken in einem Trigger erfolgen (SQL Server 2008 verfügt über eine integrierte Überwachungsfunktion).Einige der schlimmsten möglichen Änderungen (Mitarbeiter, die betrügen oder Daten böswillig vernichten wollen) kommen häufig auch von anderen Orten als der Anwendung, insbesondere wenn Sie Benutzern auf Tabellenebene Zugriff gewähren (was Sie in keiner oder einer anderen Finanzdatenbank tun sollten) Persönliche Angaben). Auditing aus der Anwendung wird dies nicht erfassen. Entwickler vergessen oft, dass beim Schutz ihrer Daten nicht nur externe Quellen die einzige Bedrohung darstellen.