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

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

编号
描述
创建
的TaskID
任务类型

除此之外，您的AuditLog表肯定应该有一个TaskType字段，否则就会发现日志中的记录代表什么类型的更改变得相对困难

另外，我会避免（尽可能）对表进行非规范化处理（即，对于给定的任务类型，列的总是为空），除非绝对必要（例如出于性能原因）。相反，我建议对任务特定列使用表和连接：

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

Answer 2

假设您正在记录事件/任务/操作，而不是修改单个表，我会选择第一个，出于同样的原因@Kragen说（upvoted）。但是如果您正在审核对个别表的更改，我会为每个被审计的表提供一个审计表。

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

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

2 个答案: