Best Practice - Protokollierung von Ereignissen (allgemein) und Änderungen (Datenbank)

Hilfe benötigen mit Protokollierung aller Aktivitäten an einem Standort sowie änderungen an der Datenbank.

Anforderungen:

  • sollte in der Datenbank
  • sollte leicht suchbar durch initiator (user-name /session-id), Ereignis (Leistungsart) und der Ereignis-Parameter

ich denken kann, ein Datenbank-design-aber entweder es beinhaltet eine Menge von Tabellen (einer pro Veranstaltung), damit ich mich einloggen kann jeder der Parameter für ein Ereignis in ein separates Feld ODER es geht um einen Tabelle mit Allgemeinen Feldern (7 int numerische und 7 text-Typen) und protokollieren alles in eine Tabelle mit der Ereignis-Typ-Feld, die Bestimmung, welche parameter habe geschrieben, wo (und in der Hoffnung, dass brauche ich nicht mehr als 7 Felder, die von einem bestimmten Typ, oder 8 oder 9 oder was auch immer Nummer, die ich wählen Sie)...

Beispiel-Einträge (die üblichen Sachen):

[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

etc...

so jemand befasste sich mit dieser vor? alle best practices /links, die Sie teilen können?

ich habe es getan mit der generischen Lösung bereits erwähnt, aber irgendwie geht gegen das, was ich gelernt habe aus Datenbank-design, aber wie Sie sehen können, die schiere Anzahl der Ereignisse, die sein müssen verfolgbar (jeder Benutzer wird in der Lage sein zu sehen, diese info) gibt mir Kopfschmerzen, ABER ich LIEBE, die ein Ereignis pro Tisch-Lösung mehr als die generischen.

irgendwelche Gedanken?

edit: außerdem, ist es vielleicht eine autoritative Liste von solchen (wahrscheinlich) Ereignisse irgendwo?

thnx

stack-überlauf, sagt: die Frage, die Sie gefragt haben, erscheint subjektiv und wird wahrscheinlich geschlossen werden.
meine Antwort: wahrscheinlich ist subjektiv, aber es ist direkt bezogen auf mein Problem habe ich mit dem entwerfen einer Datenbank /schreiben mein code, so würde ich begrüßen jede Hilfe. auch ich habe versucht, die Eingrenzung der Ideen 2, so dass hoffentlich einer von diesen wird sich durchsetzen, es sei denn, es ist bereits eine bewährte Lösung für diese Art von Dingen.

InformationsquelleAutor der Frage b0x0rz | 2010-05-09

  1. 22

    1. Protokollierung von Datenbank-änderungen, soweit inserts/deletes/updates, so weit als best practices gehen, erfolgt in der Regel durch einen trigger auf die Haupt-Tabelle schreiben von Einträgen in eine audit-Tabelle (eine audit-Tabelle pro einen echten Tisch, mit identischen columsn + Wann/was/wer Spalten).

    2. Die Liste der Ereignisse als eine generische Liste nicht vorhanden ist. Es ist wirklich eine Funktion Ihrer Anwendung/Rahmen/Umfeld/business-Bedürfnisse. So weit wie best practices, es ist eine gute Idee, um zu entscheiden, ob Sie Ihre event-Liste Typ ist 100% flat, eine 2-level-Hierarchie (Typ/Subtyp - dies ist in der Regel der beste Ansatz) - oder eine N-level-Hierarchie (viel härter/weniger effizient zu implementieren, aber unglaublich flexibel und bietet sehr schöne Möglichkeiten für eine ordnungsgemäße enterprise event management - ich hatte teilgenommen in der Umsetzung aller 3 Systeme, so spreche ich aus der Praxis, BTW).

    3. Brauchen Sie nicht 7 generische int Felder in Tabelle 1 zu speichern-Ereignis-details. Stattdessen gehen Sie für tag-value-pair-Mädchen Tabelle:

      EVENT_TYPES: (event_type, event_subtype, Beschreibung, subtype_attr1, ...) 
EREIGNISSE: (event_id, event_type, event_subtype, timestamp, attrib1, ...) 
EVENT_DETAILS: (event_id, tag, int_value, varchar_value, float_value).

      EVENT_DETAILS können normalisiert werden in EVENT_DETAILS_INT, EVENT_DETAILS_VARCHAR, EVENT_DETAILS_FLOAT, ... wenn Sie wollen, aber nicht wirklich erforderlich.

      attrib1-atttribN in der EVENTS-Tabelle sind Allgemeine Attribute, die für alle/die meisten Ereignisse, wie Benutzer-id, hostname, pid, etc...

      EVENT_TYPES ist eine Tabelle über verschiedene event-Typen/- Subtypen.

      Je nachdem, wie Sie sich entschieden Punkt #2, dieser Tisch kann flach lagern Liste von Typen, die eine Liste vom Typ/Subtyp-mappings wie in meinem Beispiel, oder eine Hierarchie von übergeordneten Art/Kind Typ (du brauchst 2 Tabellen, eine für Eltern - /Kind-Zuordnung von Typen und einen für Typ-Parametern der einzelnen Typen).

      Vielleicht möchten Sie eine zusätzliche Tabelle EVENT_TYPE_ATTRIBUTES mapping event-Typen gültigen tags für EVENT_DETAILS.

    BEISPIEL:

    Veranstaltung: [Benutzername] geklickt Ergebnis [Ergebnis Anzahl] [result id] Suche nach [Suchbegriff] und [Zahl der Ergebnisse] @datetime

    Dies würde dazu führen, dass Daten ähnlich wie diese (nicht die tatsächlichen SQL-syntax, mich verklagen :):

    EVENT_TYPES: (USER_ACTION, USER_CLICK, "auf die der Benutzer geklickt etwas") 
EREIGNISSE: (12345, "USER_ACTION","USER_CLICK", @datetime, "[username]", 
"app_name", "pid"...) 
EVENT_DETAILS: mehrere Zeilen: 
(12345, "result_number", 33, NULL, NULL) //Oder gehen Sie in die EVENT_DETAILS_INT ohne Nullen? 
(12345, "result_id", 919292, NULL, NULL) 
(12345, "search_string", NULL, ", wie kann ich protokollieren Ereignisse in der DB", NULL)

    InformationsquelleAutor der Antwort DVK

  2. -1

    Haben Sie einen Blick auf MongoDB noch? Es ist sehr schnell auf Einsätze, da Sie nicht haben ein paar features, die relation Datenbanken wie MySQL haben, und natürlich können Sie die Suche über alle Felder, die Sie in Ihren Daten. Eigentlich, die meisten Unternehmen beginnen, es zu verwenden für die Datenerfassung und-Analysen zunächst vor der Behandlung komplexer Anwendungen mit.

    InformationsquelleAutor der Antwort Thomas R. Koll

Schreibe einen Kommentar