1

最初,我正在考虑一个可以处理所有审计日志的表,但就灵活性而言,例如在未来,您认为打破表并让每个应用程序拥有自己的审计日志是有意义的桌子?

例如,对于预订,我将有一个审核表来跟踪字段级别的所有更改,然后我将有另一个用于签证申请的审核表。

我目前的审计日志表设计是这样的

AuditLogID
Module              
ActivityType
ReferenceNumber 
FieldName
OldValue
NewValue
IPAddress
4

1 回答 1

1

您所描述的模式似乎与实体属性值 (EAV) 一致,即每个字段一行。

假设所有模块中所有表的所有字段更改都会导致新的审计行,这种方法存在一些潜在问题

  • 审计表会变得非常大
  • 写入的数量会很大且很频繁,可能会对性能产生负面影响 - 此审计表的正确集群非常重要
  • 为了查看/比较行,您需要将字段重新组合成行以便对用户有意义

您还可能会错过 2 个重要的审计属性,即更改的 UserId 和 TimeStamp

您可以对审计表进行一些规范化,例如,有一个“每行一个”审计表和一个“每字段一个”审计表。例如,IP 地址、ReferenceNumber、Activity Type、UserId 和 TimeStamp 可能是同一行中所有更新字段的常量,这些字段由单个“操作”更改并且每行一次属于一次。

还有其他选择

  • 每个 Live 表一个 Audit 表,通常是字段的克隆,加上一个 TimeStamp 字段和一个新的主键(或将其保留为堆)
  • SQL 变更数据捕获 SQL Server 2008 变更数据捕获与审计跟踪中的触发器
  • 如果所有更改都来自同一个应用程序,您可以使用文档存储(例如,将行存储为 Xml、Blob 或其他元数据),将更改的序列化版本保存在一行中,并且可能只公开几个可索引字段(列名称,日期)用于查询目的。
  • 如果您选择文档存储方法,您也可能选择根本不在 RDBMS 中存储审计数据。像 RavenDB 或 MongoDB 这样的 NoSQL 存储擅长存储大容量
于 2012-06-03T11:57:28.973 回答