Empfohlenes Modell für die Ereignisprotokollierung auf Anwendungsebene

Ich werde Ereignisse auf Anwendungsebene (Benutzer A hinzugefügt, Benutzer B hat das aktualisiert usw.) sowohl für den öffentlichen als auch für den privaten Verbrauch speichern.

Unten finden Sie ein stark vereinfachtes Modell der Tabellen und ihrer Zuordnungen.

users
-------
id (PK)

event_type
-------
id (PK)
description

events
-------
id (PK)
user_id (FK)
event_type_id (FK)
created (timestamp)

Die Ereignisse werden für jeden Benutzer in einem Zeitleistenformat (neueste Ereignisse oben) gemeldet.

Ich möchte auch benutzerdefinierte Uri-Parameter und den Ereigniskontext hinzufügen (Benutzer A aktualisiert "Meine Visa-Karte").

Übersehe ich mögliche Fallstricke in diesem Design?

Ihr Grundmodell ist in Ordnung. Sie erhalten eine standardisierte, normalisierte Schnittmenge (viele bis viele) von Ereignissen bestimmter Typen, die bestimmten Benutzern zugeordnet sind. Ohne mehr über Ihre Absichten oder Anforderungen zu wissen, ist es schwierig, Kritik am Modell zu üben.

Ich würde diese Beobachtungen machen:

1. Sie können events.idfür Ihre PK auf dem eventsTisch verwenden, wenn Sie möchten. So würde ich es wahrscheinlich machen. Sie haben jedoch die Wahl, die PK aus eventder Kombination von events.user_idund zu erstellen event_type_id. Dies ist genauso gut, möglicherweise etwas besser, wenn Sie keine anderen Tabellen haben, die direkt auf die eventsTabelle verweisen . Der potenzielle Vorteil muss im Hinblick darauf berücksichtigt werden, wie Sie den Platz für diese Tabelle verwalten möchten und wie schnell sich Ereignisse ansammeln. Durch die Verwendung events.idals Clustering-Index kann ein Hotspot erstellt werden. Auf der anderen Seite kann die Verwendung des zusammengesetzten Schlüssels zu langen Verzögerungen bei Ihren Einfügungen führen, wenn Sie Ihre Seitenfüllungen nicht ordnungsgemäß verwalten.

2. Sie haben erwähnt, dass das Modell vereinfacht ist, aber Sie haben nicht gesagt, auf welche Weise. Eine Sache, die ich sagen würde, ist, dass das vorgestellte Modell nur sehr wenige Informationen über Ereignisse liefert. Sie wissen, wer was (und wann) getan hat - aber das Was ist auf eine statische Beschreibungszeichenfolge beschränkt. Andere Ereignisprotokollierungssysteme, die ich gesehen (und erstellt) habe, enthalten Orte zum Aufzeichnen bestimmter Details des Objekts des Ereignisses. Wenn ich du wäre, würde ich mir Fragen stellen wie:

   • Wäre es hilfreich, wenn in der eventsTabelle ein Textfeld vorhanden wäre, das mit spezifischen Details zu den Ereignissen während der Veranstaltung gefüllt werden könnte?

   • Wäre es hilfreich, Spalten zu haben, die aufzeichnen, welche Instanz eines anderen Elements von der Aktion betroffen war (dh: events.object_typeund events.object_id)?

   • Gibt es komplexe Ereignisse mit mehreren Teilen, die zu einem einzigen logischen Ereignis zusammengefasst werden sollten? Wäre es eventshilfreich , ein Feld zu haben, in dem mehrere Datensätze miteinander verknüpft werden können?

Wenn Sie uns mehr darüber erzählen können, wie Sie die Ereignisse nutzen möchten, und aus der Perspektive, wie die Informationen hilfreich sein sollen, kann ich Ihnen möglicherweise konkretere Ratschläge geben.

Eine der von mir verwalteten Anwendungen hat eine ähnliche Struktur, ergänzt sie jedoch durch eine application_event_type-Tabelle

ID,VALUE  
0,CREATE  
1,ASSIGN  
3,UPDATE  
2,DELETE  
4,UNASSIGN  
5,APPROVE  
6,MARK_AS_DUPLICATE  

und der Mastertisch sieht so aus

CREATE TABLE APPLICATION_LOGGING  
(  
  ID                  NUMBER(9)                 NOT NULL,   
  CURRENT_USER_ID     NUMBER(9),  
  EVENT_ID            NUMBER(9)                 NOT NULL,  
  ENTRY_DATE          DATE                      NOT NULL,  
  MESSAGE             VARCHAR2(200 CHAR)        NOT NULL,  
  MESSAGE_PARAMETERS  VARCHAR2(2000 CHAR)       NOT NULL  
)  

Ich fand, dass die Protokollierung etwas ist, an dem mehr Menschen interessiert sind, als ich erwartet hätte. Manager wollen wissen, wer was getan hat. Für sie reichte ein kryptischer Protokolleintrag nicht aus. Message und Message_parameters waren lange Textzeichenfolgen mit zu vielen Informationen. Ich musste eine Verknüpfungstabelle erstellen, die die Nachricht und die Nachrichtenparameter auf Englisch oder Französisch verdichtete

CREATE TABLE APPLICATION_LOGGING_NEW
(
  ID                        NUMBER(10)         NOT NULL,  
  LOG_ID                    VARCHAR2(50 BYTE)  NOT NULL,  
  EVENT_ID                  NUMBER(10),   
  MESSAGE                   VARCHAR2(500 BYTE) NOT NULL,  
  LOCALE_ID                 NUMBER(10)         DEFAULT 2    NOT NULL,  
  LOG_TYPE                  NUMBER(10)         DEFAULT 1    NOT NULL,   
  DATE_CREATED              TIMESTAMP(6)       DEFAULT CURRENT_TIMESTAMP NOT NULL,  
  CREATED_BY_USER_ID        NUMBER(9)          DEFAULT 355  NOT NULL,
  DATE_LAST_MODIFIED        TIMESTAMP(6)       DEFAULT CURRENT_TIMESTAMP NOT NULL,
  LAST_MODIFIED_BY_USER_ID  NUMBER(9)           DEFAULT 355 NOT NULL  
)  

Eine andere Datenbank, mit der ich arbeite, verfügt über eine umfangreiche Protokollierung. Jedes Mal, wenn Sie sich etwas "ansehen", wird eine Einfügung durchgeführt. Dies schien eine großartige Funktion zu sein, aber die Protokollierungstabelle ist jetzt dreimal so groß wie die fünf größten Tabellen. Das Abfragen und Einfügen dieser Tabelle wirkt sich eindeutig auf die Leistung aus.

Protokollierung ist eine gute Kunst: Zu viel und Sie können die Leistung beeinträchtigen, nicht genug und Sie können keine vernünftige Frage beantworten. Es lohnt sich, die Zeit zu investieren, um das richtige Gleichgewicht zu finden.