应用程序级事件日志的推荐模型

Question

我将存储应用程序级事件(用户A添加了东西，用户B更新了该事件等等)，以供公共和私人使用。

下面是表及其关联的过于简化的模型。

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

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

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

每个用户将以时间线格式(顶部的最新事件)报告事件。

我还想添加自定义uri参数和事件上下文(用户A更新了“我的Visa卡”)。

我是否忽略了这个设计中任何潜在的陷阱？

Answer 1

你的基本型号很好。它为您提供了与特定用户关联的特定类型的事件的标准、规范化的交集(多到多)。如果不了解更多您的意图或需求，就很难对模型提出任何批评。

我要提出以下意见：

1. 如果您愿意，可以在events.id表上为您的PK使用events。我可能就是这样做的。但是，您可以考虑将event的PK作为events.user_id和event_type_id的组合。如果没有其他直接引用events表的表，这也同样好，可能稍微好一点。必须根据您计划如何管理此表的空间以及事件积累的速度来考虑潜在的优势。使用events.id作为聚类索引可以创建一个热点。另一方面，如果您不能正确地管理页面填充，使用复合键可能会在插入中造成长时间延迟。
2. 您已经提到了模型是简化的，但您还没有说明以何种方式。我要说的一件事是，所提出的模型很少给出关于事件的信息。您知道是谁做了什么(以及什么时候)-但是什么仅限于静态描述字符串。我看到(并构建)的其他事件日志系统包括记录事件对象的特定细节的位置。如果我是你，我会问自己这样的问题：
   • 如果events表中有一个文本字段可以填充事件期间发生的具体细节，会有帮助吗？
   • 如果列记录另一项的哪个实例受到操作(即：events.object_type和events.object_id)的影响，会有帮助吗？
   • 是否有多个部分应该分组为一个逻辑事件的复杂事件？有一个允许将多个events记录绑定在一起的字段会有帮助吗？

如果你能告诉我们更多关于你计划如何使用这些事件的信息，从这些信息是如何有帮助的角度来看，我也许可以给你更具体的建议。

Answer 2

我维护的其中一个应用程序具有类似的结构，但通过拥有一个application_event_type表添加到其中。

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

主表看起来像这样

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  
)  

我发现伐木是比我想象中更多的人感兴趣的东西。经理们想知道是谁干的。对他们来说，一个神秘的日志条目是不够的。消息和Message_parameters是冗长的文本字符串，信息太多。我不得不制作一个连接表，将信息和消息参数浓缩为英文或法文。

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  
)  

我使用的另一个数据库具有广泛的日志记录。每当你“看”某件事时，插入就会被完成。这似乎是一个很好的特性，但是日志记录表的大小现在是前五大表的三倍。查询和插入此表对性能有一定的影响。

伐木是一门很好的艺术:太多，你会影响性能，不够，你不能回答一个合理的问题。花时间寻找合适的平衡是非常值得的。