SQL - 审计日志表设计 - 你更喜欢哪一个？

Question

对于我正在从事的公司正在建立的项目，我们需要对用户执行的各种任务（对系统中的表所做的更改）进行审核（存储日志）。目前，只有三种不同类型的任务。但这可能会在未来增长。

我对此的建议是以下架构表和关系（示例）：

Table AuditLog
------------------------------
Id | PK
Description
Created

对于每一项任务：

Table ExampleTaskAuditLog
------------------------------
ExampleTaskId | FK PK
AuditLogId | FK PK

还有：

Table AnotherExampleTaskAuditLog
------------------------------
AnotherExampleTaskId | FK PK
AuditLogId | FK PK

基本上，对于我们需要审核的每一种任务，我们都会有一个保存关系的新表。

另一位开发者的建议如下：

Table AuditLog
------------------------------
Id (PK)
Description
Created
ExampleTaskId | NULLABLE
AnotherExampleTaskId | NULLABLE
Type | (an integer id which indicates whether this is a "example task" or a "another example task").

基本上，如果我们要为“ExampleTask”创建日志，我们会将 ExampleTaskId-field 设置为示例任务的标识，并将 Type 设置为相应的 ExampleTask-enum 值。

他建议上表是因为他在争论完整性（我认为这很好！）和性能。主要是因为存在 FK 约束，并且需要加入表才能获取相关日志（是的，这是 RMDBS - MSSQL）。此外，由于每个日志都有两个表，因此还需要两个插入（完整性查找等）。当然，这是正确的。但我看不到问题。特别是没有性能，因为它是最小的。此外，第一年要存储的日志总量很可能不会超过 5-10K。几年后，这些表最多可能包含大约 30-40K 行。

您对以上内容有何看法？另外，您更喜欢上述哪一种解决方案，为什么？

Answer 1

假设您正在记录事件/任务/操作，而不是对单个表的修改，我会选择第一个，原因与@Kragen 所说的相同（赞成）。但是，如果您要审计对个别表的更改，我会为每个要审计的表使用一个审计表。

一个附带问题，你真的想要那些外键吗？如果表中的某个项目（行）被删除，则您必须删除该项目的审计跟踪。您只需要现有项目的审核日志吗？ （“审计”通常意味着“观察他们在做什么”，如果“他们”可以抹去他们通常不受欢迎的活动的所有痕迹，即使在华尔街也是如此。）

Answer 2

我不确定我是否完全理解 - 如果 ExampleTaskId 和 AnotherExampleTaskId 是相同的数据类型，为什么不只使用一个包含以下列的表？

• 身份证
• 说明
• 已创建
• 任务 ID
• 任务类型

除此之外，您的AuditLog 表肯定应该有一个TaskType 字段，否则很难确定日志中的记录代表什么类型的更改。

此外，除非绝对必要（例如出于性能原因），否则我会避免（在可能的情况下）对表进行非规范化（即，对于给定的任务类型，具有始终为空的列）。相反，我建议对任务特定的列使用表和连接：

Table ExampleTaskAuditLog
------------------------------
AuditId (PK)
TaskSpecificField
AnotherTaskSpecificField