审计表：一个表或一个表的每个字段

Question

我的项目中一切都很好，除了审计字段。只需插入和更新即可在我们想象的宇宙中进行审核。

我提出了一个类似于以下示例的表格：

• best design for a changelog / auditing database table?

• Suggestions for implementing audit tables in SQL Server? 只是表名、表列、用户、操作和日期。

但我的团队不这么认为，他们在每个表上放置一列来跟踪更新或插入时间。当我问为什么？他们告诉我这是他们在工作中保持跟踪的方式。

最后我放弃了，我把每个字段都放在了每张桌子上。因为除了我之外的所有团队，都叫我放那个字段。

例子：

他们的方法

Table Customer
+-------------+-------------+-----+--------------------------------+-------------+
| Name        | LastName    | ... | LastModification (Audit Field) | User        |
+-------------+-------------+-----+--------------------------------+-------------+
| varchar(30) | varchar(50) | ... | datetime                       | varchar(30) |
+-------------+-------------+-----+--------------------------------+-------------+

我的方法

Table Customer
+-------------+-------------+-----+
| Name        | LastName    | ... |
+-------------+-------------+-----+
| varchar(30) | varchar(50) | ... |
+-------------+-------------+-----+

Table Audit
+-----------+------------+--------+------+-------------+
| TableName | TableField | Action | User | DateAndTime |
+-----------+------------+--------+------+-------------+

所以问题是：

哪种设计更好，一张表保留交易历史记录，还是每张表一个字段？ （优点和缺点）

Answer 1

这是一个更好的设计，一张保留历史的桌子 事务或每个表的一个字段？ （优点和缺点）

这里不是专注于 2 个选择，而是我多年来使用的 4 种方法的答案。各有优缺点。

1。只有三个字段

只需向每个表添加三个字段（last action、time_stamp、update_user），就可以结束了。

优点超级简单。表现不错

缺点您无法报告您没有的数据，因此这种结构几乎不会告诉您任何信息（删除除外）

2。克隆表

每个表都有一个副本加上三个审计字段，每次用户更改记录时，审计表都会插入其中。

优点表现不错。轻松创建用户可以挖掘的逐行历史记录。

缺点

• 对基表的每次更改都需要对审计表进行相应的更改。
• 如果用户不想逐行挖掘历史记录，并且他们想要一份关于具体更改内容的报告，那么它可能会很快变得令人讨厌。查看How can I write a query to extract individual changes from snapshots of data?的答案

3。仅限历史记录表

没有基表，只有历史表。 这与克隆表基本相同，只是现在您必须始终获取当前记录。

优点 2 的优点，但一切都是插入。比选项 2 更少的维护。

缺点你最终会失去维护收益，因为你最终会维护视图，或者你会在各处散布获取当前记录的逻辑

4。通用审计表

此表有四列（Table*、Column_name、old_value、new_value）和三个审计字段。

优点易于设置和维护。

缺点

• 它不直观，但会占用大量空间，因为您的 old_value 和 new_value 字段必须为 nvarchar(max) 或等效字段，以便它可以接受基表中的任何内容。

• 读写性能不佳。

• 逐行设置历史报告很痛苦

• 如果记录中存在任何类型的工作流，审计报告可能会变得非常重要。例如，您要求用户只想查看记录状态变为“已批准”后发生的更改。即使在选项 2 和 3 中也很难做到这一点，但在通用审计方法中却是一场灾难。

总结

我更喜欢 #2 克隆表方法，因为它似乎最适合我。我遇到过 #1 不足的问题，而 #4 可能是一场严重的性能噩梦，需要大量工作才能撤消。