Bewährte Verfahren - Protokollierung von Ereignissen (allgemein) und Änderungen (Datenbank)

Question

Hilfe brauchen bei Protokollierung aller Aktivitäten auf einer Website sowie von Datenbankänderungen .

Anforderungen:

• sollte in der Datenbank sein
• sollte leicht nach Initiator (Benutzername/Sitzungsnummer), Ereignis (Aktivitätsart) und Ereignisparametern durchsuchbar sein

Ich kann an ein Datenbankdesign denken, aber entweder beinhaltet es viele Tabellen (eine pro Ereignis), so dass ich jeden der Parameter eines Ereignisses in einem separaten Feld protokollieren kann ODER es beinhaltet eine Tabelle mit generischen Feldern (7 int numerisch und 7 Texttypen) und protokollieren alles in einer Tabelle mit Ereignis-Typ-Feld bestimmen, welche Parameter wo geschrieben wurde (und hoffen, dass ich nicht mehr als 7 Felder eines bestimmten Typs, oder 8 oder 9 oder welche Anzahl ich wählen)...

Beispiel für Einträge (die üblichen Dinge):

[username] login failed @datetime
[username] login successful @datetime
[username] changed password @datetime, estimated security of password [low/ok/high/perfect]  @datetime
[username] clicked result [result number] [result id] after searching for [search string] and got [number of results] @datetime
[username] clicked result [result number] [result id] after searching for [search string] and got [number of results]  @datetime
[username] changed profile name from [old name] to [new name]  @datetime
[username] verified name with  [credit card type] credit card  @datetime
datbase table [table name] purged of old entries @datetime via automated process

usw...

also Hat sich jemand schon einmal damit beschäftigt? ? beliebig beste Praktiken / Links, die Sie teilen können ?

Ich habe gesehen, dass es mit der oben erwähnten generischen Lösung getan, aber irgendwie das geht gegen das, was ich aus Datenbank-Design gelernt, aber wie Sie sehen können die schiere Anzahl von Ereignissen, die nachverfolgt werden müssen (jeder Benutzer in der Lage sein, diese Informationen zu sehen) ist mir Kopfschmerzen, ABER ich LIEBE das ein Ereignis pro Tabelle Lösung mehr als die generische ein.

irgendwelche Gedanken?

edit: Gibt es vielleicht irgendwo eine verbindliche Liste solcher (wahrscheinlicher) Ereignisse?

thnx

Stack Overflow sagt: Die Frage, die Sie stellen, scheint subjektiv zu sein und wird wahrscheinlich geschlossen werden.
meine Antwort: wahrscheinlich ist subjektiv, aber es ist direkt mit meinem Problem verbunden, das ich mit dem Entwerfen einer Datenbank / dem Schreiben meines Codes habe, also würde ich jede Hilfe begrüßen. auch ich habe versucht, die Ideen auf 2 einzugrenzen, also hoffentlich wird sich eine davon durchsetzen, es sei denn, es gibt bereits eine etablierte Lösung für diese Art von Dingen.

Answer 1

1. Die Protokollierung von Datenbankänderungen wie Einfügungen/Löschungen/Aktualisierungen erfolgt in der Regel durch einen Trigger in der Haupttabelle, der Einträge in eine Audit-Tabelle schreibt (eine Audit-Tabelle pro echter Tabelle, mit identischen Spalten + Wann/Was/Wer-Spalten).

2. Die Liste der Ereignisse als allgemeine Liste gibt es nicht. Es ist wirklich eine Funktion von Ihrer Anwendung/Framework/Umgebung/Geschäftsanforderungen. Was die besten Praktiken angeht, ist es eine gute Idee zu entscheiden, ob Ihre Ereignistypenliste 100 % flach ist, eine zweistufige Hierarchie (Typ/Subtyp - dies ist in der Regel der beste Ansatz) oder eine n-stufige Hierarchie (viel schwieriger/weniger effizient zu implementieren, aber unglaublich flexibel und bietet sehr schöne Möglichkeiten für ein angemessenes Unternehmens-Ereignismanagement - ich habe an der Implementierung aller 3 Schemata teilgenommen, ich spreche also aus der Praxis).

3. Sie brauchen keine 7 generischen int-Felder in einer Tabelle, um Ereignisdetails zu speichern. Wählen Sie stattdessen eine Tag-Wert-Paar-Tabelle:

   EVENT\_TYPES: (event\_type, event\_subtype, description, subtype\_attr1, ...)
   EVENTS: (event\_id, event\_type, event\_subtype, timestamp, attrib1, ...)
   EVENT\_DETAILS: (event\_id, tag, int\_value, varchar\_value, float\_value).

   EVENT_DETAILS kann in EVENT_DETAILS_INT, EVENT_DETAILS_VARCHAR, EVENT_DETAILS_FLOAT, ... normalisiert werden, wenn Sie es wünschen, aber nicht wirklich erforderlich.

   attrib1-atttribN in der Tabelle EVENTS sind allgemeine Attribute, die für alle/den Großteil der Ereignisse gelten, wie z.B. userid, hostname, pid, etc.

   EVENT_TYPES ist eine Tabelle, die verschiedene Ereignistypen/Subtypen beschreibt.

   Je nachdem, wie Sie sich für Aufzählungspunkt 2 entschieden haben, kann diese Tabelle eine flache Liste von Typen, eine Liste von Typ/Untertyp-Zuordnungen wie in meinem Beispiel oder eine Hierarchie von übergeordnetem Typ/untergeordnetem Typ speichern (dafür benötigen Sie zwei Tabellen, eine für die übergeordnete/untergeordnete Zuordnung von Typen und eine für die Typattribute jedes Typs).

   Sie können eine weitere Hilfstabelle EVENT_TYPE_ATTRIBUTES einrichten, die die Ereignistypen den gültigen Tags für EVENT_DETAILS zuordnet.

---

BEISPIEL :

Ereignis: [Benutzername] hat auf Ergebnis [Ergebnisnummer] [Ergebnis-ID] geklickt, nachdem er nach [Suchbegriff] gesucht hat und [Anzahl der Ergebnisse] @datetime erhalten hat

Dies würde zu Daten führen, die in etwa wie folgt aussehen (keine aktuelle SQL-Syntax, verklagt mich :):

EVENT\_TYPES: (USER\_ACTION, USER\_CLICK, "User clicked something")
EVENTS: (12345, "USER\_ACTION","USER\_CLICK", @datetime, "\[username\]", 
         "app\_name", "pid"...) 
EVENT\_DETAILS: several rows:
 (12345, "result\_number", 33, NULL, NULL) // Or go into EVENT\_DETAILS\_INT without NULLs? 
 (12345, "result\_id", 919292, NULL, NULL)  
 (12345, "search\_string", NULL, "how do I log events in DB", NULL)