为了审计的目的，为我们的每个web应用程序模块创建单独的表好吗？

Question

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

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

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

AuditLogID
Module              
ActivityType
ReferenceNumber 
FieldName
OldValue
NewValue
IPAddress

Answer 1

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

假设对所有模块中的所有表所做的所有字段更改都将产生一个新的审计行，则此方法存在一些潜在问题

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

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

也许你可以对你的审计表做一些标准化，例如，有一个“每行一个”的审计表和一个“每个字段一个”的审计表。例如，IP地址、ReferenceNumber、活动类型、UserId和TimeStamp可能是同一行中的所有更新字段的常量，这些字段由单个“动作”改变，并且属于每行一次。

还有其他的选择。

• 每个Live表一个审计表，通常是字段的克隆，加上一个TimeStamp字段和一个新的主键(或者只是将其作为堆)
• SQL change Data Capture SQL Server 2008 change data capture vs triggers in audit trail
• If所有的更改都发生在同一个应用程序中，您可以使用文档存储(例如，将行存储为Xml、Blobs或其他元数据)，将更改的序列化版本保存在单行中，并可能只是出于查询目的而公开几个可索引的字段(列名、日期)。
• 如果选择文档存储方法，还可以选择根本不在关系数据库中存储审计数据。像RavenDB或MongoDB这样的NoSQL商店擅长存储高容量