database - 审计表 : Each field for table or one table

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

Which is a better design, one table that keep the history of transactions or one field for each table? (Pro and cons)

这里不是关注这 2 个选择，而是对我多年来使用的 4 种方法的回答。各有利弊。

1。就三个字段

只需将三个字段(上次操作、时间戳、更新用户)添加到每个表中，然后就可以收工了。

优点 super 简单。表现良好

缺点 您无法报告您没有的数据，因此此结构几乎什么也告诉您(删除除外)

2。克隆表

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

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

缺点

• 对基表的每次更改都需要对审计表进行相应的更改。
• 如果用户不希望逐行挖掘历史记录，而他们想要一份关于究竟发生了什么变化的报告，这可能会在匆忙中变得令人讨厌。查看 How can I write a query to extract individual changes from snapshots of data? 的答案

3。仅限历史表

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

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

缺点 你最终会失去维护 yield ，因为你最终会维护 View ，或者你会到处散布获取当前记录逻辑

4。通用审计表

此表有四列( Table*, Column_name, old_value, new_value )和三个审计字段。

优点 易于设置和维护。

缺点

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

• 读写性能不佳。

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

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

总结

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