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字段集合到示例任务的身份和键入相应的ExampleTask-enum值。

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

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

Answer 1

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

• 编号
• 说明
• 创建
• 任务id
• 任务类型

这且不说，你AuditLog表绝对应该有一个TaskType场，否则就变得相对困难弄清楚记录在哪种类型的记录中日志代表。除非绝对必要（例如性能方面的原因），否则我会避免（在可能的情况下）对您的表进行非规格化（即，对于给定的任务类型，列将始终为空）。相反，我推荐使用表和联接的任务具体列：

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

Answer 2

假设你正在登录事件/任务/行动，而不是修改单个表，我会与第一次去，对同一@Kragen说的原因（upvoted）。但是，如果您正在审核对单个表的更改，那么我将为每个正在审计的表使用一个审计表。

一个问题，你真的想要那些外键吗？如果表中的项目（行）被删除，那么您将不得不删除该项目的审计线索。你只需要现有项目的审计日志？ （“审计”一般意味着“观察他们的行为”，如果“他们”能够消除他们通常不赞成的活动的痕迹，即使在华尔街也是如此）。