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

raz*_*tia 18 database audit

除了审计字段之外,我的项目中的一切都很好.只是插入和更新正在我们想象的宇宙中进行审核.

我提出了一个类似于下一个例子的表:

但是我的团队没有想到同样的方式,他们在每个表上放置一列来跟踪更新或插入时间.当我问为什么?他们告诉我,这就是他们在工作中保持轨道的方式.

最后我放弃了,我把每个字段放在每张桌子上.由于除了我以外的所有团队,都告诉我把那些领域.

例:

他们的方法

Table Customer
+-------------+-------------+-----+--------------------------------+-------------+
| Name        | LastName    | ... | LastModification (Audit Field) | User        |
+-------------+-------------+-----+--------------------------------+-------------+
| varchar(30) | varchar(50) | ... | datetime                       | varchar(30) |
+-------------+-------------+-----+--------------------------------+-------------+
Run Code Online (Sandbox Code Playgroud)

我的方法

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

Table Audit
+-----------+------------+--------+------+-------------+
| TableName | TableField | Action | User | DateAndTime |
+-----------+------------+--------+------+-------------+
Run Code Online (Sandbox Code Playgroud)

所以问题是:

哪个是更好的设计,一个表保存事务的历史记录或每个表的一个字段?(正确和缺点)

Con*_*rix 30

哪个是更好的设计,一个表保存事务的历史记录或每个表的一个字段?(正确和缺点)

而不是关注这两个选择,这是我多年来与之合作的4种方法的答案.每个都有其优点和缺点.

只有三个领域

只需在每个表中添加三个字段(last action,time_stamp,update_user)并将其调用一天.

优点超级容易.表现很好

缺点您无法报告您没有的数据,因此此结构几乎不会告诉您任何内容(删除除外)

2.克隆表

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

优点表现相当不错.易于创建用户可以挖掘的逐行历史记录.

缺点

3.仅限历史表

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

优点 2优点,但一切都是插入.选项2减少维护.

缺点你最终会失去维护收益,因为你最终会维护视图,或者你会在整个地方洒上当前记录逻辑

4.通用审计表

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

优点易于设置和维护.

缺点

  • 它不直观,但它占用了大量的空间,因为你old_valuenew_value字段必须是nvarchar(max)或等价的,所以它可以接受你的基表中的任何东西.

  • 在读写时执行效果不佳.

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

  • 如果记录中存在任何类型的工作流程,则审计报告可能变得非常重要.例如,您要求用户只希望查看记录状态变为"已批准"后发生的更改.即使在选项2和3中这也很难,但在通用审计方法中变成了灾难.

摘要

我更喜欢#2 Clone table方法,因为它似乎对我来说效果最好.我遇到的问题是#1不足,#4可能是一个严重的噩梦,需要大量的工作才能撤消.