Question

我意识到这个问题很普遍，但我认为在事件跟踪方面有很多经验的人会有很好的洞察力。

我有一个网站，我希望用户跟踪文件下载。我想到了两种方法：

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

我看到以下优点和缺点：

方法1：

Pro - 更好的可读性，因为 model完全代表事件
Pro - 不需要重构如果事件发生变成单独的事件太不一样了
Pro - 不需要搜索事件表上有一个额外的参数时间（“事件类型”）
Con - 潜在的大量表格
Con - 虽然可能不是很干他们可以继承一般与之无关的事件模型用桌子，或者我可以实现一个 “充当可跟踪的”宝石

方法2：

专业版 - 只有一张表适用于所有内容
Pro - DRY默认情况下
Con-Table可能成为非常宽，只有列适用于一小部分事件
Con - 可能需要重构未来的具体事件

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

但是，我现在正在另一个网站上成功使用方法2。只是想看看其他人在做什么。

更新

我想提一下，我正在记录的事件需要经常访问。我将提供一个仪表板，用户可以按用户和日期查看文件下载。如果您的答案涉及使用审核日志模型

，请考虑这一点

Answer 1

方法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审核日志模型。

Answer 2

有第三种选择：

event_header: 
  id
  date
  time
  type
  code
  ... 

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

您的下载查询知道事件类型为4，因此在event_data表上进行连接

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

Overcomplication？也许。慢点？大概。对未来的开发者感到困惑？是。是否可行？当然。

我，我可能会使用方法2并使用JSON或XML格式的特殊数据的文本字段，或者只是“key：value，key：value”

Answer 3

多年来，我一直在设计中使用方法2。表格宽度从来都不是一个问题，因为它通常对于事件描述非常重。我想这意味着任何审核审核都需要审核员进行一些手工解析，但是当您处于审核阶段时，通常会在任何设计中发现这种检测工作。

最近，解决表格宽度的一种方法是在XML blob中存储有关事件的大量细节。 MSSQL最近支持它很好，我可以构建任何简单的报告工具来提供它。在重新分解特定事件等方面......这通常归结为报告工具。我当然不是数据模型专家，我无法就非常大型表格向您提供建议，但过去与数据库人员合作他们总是更喜欢方法2并拥有构建视图/报告/等等。在那附近。

在单独的模型或一个事件模型中跟踪事件是否更好？

3 个答案: