为审计目的创建每个Web应用程序模块的单独表是否合适？

Question

最初，我正在考虑一个将处理所有审计日志的表，但就灵活性而言，例如将来您认为，打破表并让每个应用程序都拥有它们是有意义的自己的审计日志表？

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

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

AuditLogID
Module              
ActivityType
ReferenceNumber 
FieldName
OldValue
NewValue
IPAddress

Answer 1

您描述的模式似乎与实体属性值（EAV）一致，即每个字段一行。

假设所有模块中所有表的所有字段更改都将导致新的审核行，则此方法存在一些潜在问题

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

您还可能错过了两个要审核的重要属性，即更改的UserId和TimeStamp

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

还有其他选择

• 每个Live表一个Audit表，通常是字段的克隆，加上TimeStamp字段和新的主键（或者只是将其保留为堆）
• SQL Change Data Capture SQL Server 2008 change data capture vs triggers in audit trail
• 如果所有更改都来自同一个应用程序，则可以使用文档存储 （例如，将行存储为Xml，Blob或其他元数据），保留 单行中的变化的序列化版本，可能只是 公开几个可索引字段（列名，日期）以供查询 目的。
• 如果选择文档存储方法，也可以选择 根本不选择将审计数据存储在RDBMS中。 NoSQL商店喜欢 RavenDB或MongoDB擅长存储大量数据