代码之家 › 专栏 › 技术社区 › Tony

在单独的模型中跟踪事件是更好还是一个事件模型更好?

architecture database-design

Tony · 技术社区 · 15 年前

我知道这个问题很笼统,但我认为在事件跟踪方面有丰富经验的人会有很好的洞察力。

我有一个网站,我想跟踪文件下载的用户。想到两种方法:

1) 创建一个名为AssetDownload的模型并用数据填充该模型。
2) 创建一个名为Event或Activity的模型,并将其作为跟踪事件的通用模型。

我看到了以下优点和缺点:

方法1:

亲-更好的可读性,因为模型准确地表示事件
Pro不需要重构太不一样了
亲将不需要搜索事件表中的一个额外参数时间(“事件类型”)
可能有很多表
不过,可能不是很干他们可以继承将军的遗产未关联的事件模型

方法2:

专业-所有东西只有一张桌子
默认为Pro-DRY
Con-Table将可能成为非常宽,只有
未来的具体事件

我很想使用方法1,因为它是一种最基本的可行的产品思考过程。只要做我需要的,我最终会添加5个模型,每个事件类型1个。如果我添加20个模型,那么我可以使用一个表继承方案进行重构。但至少在那一点上,我会知道我在重构什么,而为未来而设计现在需要一些猜测。

然而,我现在在另一个网站上成功地使用了方法2。只是想看看别人在做什么。

更新

我想提到的是,我记录的事件需要经常访问。我将提供一个仪表板,用户可以查看文件下载的用户和日期。如果您的答案涉及使用审计日志模型,请考虑这一点。

3 回复 | 直到 15 年前

Richard Harrison 15 年前

方法2是 正确的 做这件事的方法。我一直都是这样做的,只是我称之为审计日志,使它非常通用,并用于很多事情。

如果您需要创建多种类型的条目,请不要将表变宽,而是使用多个条目。

伪DDL-类型可能不同。

CREATE TABLE Audit
   Type           # FK identifying the entry type
   DateTime       # entry time
   RequesterID    # FK identifying the user/process initiating the request
   Object         # Filename etc.
   ObjectClass    # FK defining type of the object 
   AccessType     # FK defining the type of access (download etc.)
   AccessOverride # FK set if accessed via impersonation
   Status         # FK result of operation - success / fail
 ;

注意:最初这是基于VMS审计日志模型的。

Chris K 15 年前

有第三种选择:

event_header: 
  id
  date
  time
  type
  code
  ... 

event_type_data: 
  PK(id)
  FK(event_id)
  special_field1
  special_field2

您的下载查询知道事件类型是4,所以对event\ u数据表进行连接

select ev.*, evd.* from event_header ev, event_type_data evd where evd.event_id = ev.id and ev.type = 4

对于我来说,我可能会使用方法2,为JSON或XML格式的特殊数据提供一个文本字段,或者简单地说“key:value,key:value”

David 15 年前

这些年来,我在设计中通常使用方法2。表的宽度从来没有作为一个问题出现过,因为对于事件描述来说,它通常是非常繁重的字符串。我想这意味着任何审计审查都会涉及到审计人员的大量手工分析,但是当你在审计的时候,这种检查工作通常会出现在任何设计中。

对我来说,最近解决表宽度问题的一种方法是在一个XML blob中存储有关事件的许多细节。MSSQL现在已经很好地支持它了,而且我可以构建任何简单的报告工具来从中获取信息。在重新分解特定事件等方面。。。这通常归结为报告工具。我当然不是数据模型专家,也不能给你建议大型表,但在过去与数据库人员合作时,他们也总是首选方法2,并围绕方法2构建视图/报告等。