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

时间：2011-11-02 02:52:32

标签： database audit

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

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

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

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

示例：

他们的方法

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 |
+-----------+------------+--------+------+-------------+

所以问题是：

哪个是更好的设计，一个表保存事务的历史记录或每个表的一个字段？ （正确与否）

1 个答案:

答案 0 :(得分：30)

  

这是一个更好的设计，一个保持历史的表   每个表的交易或一个字段？ （正确与否）

这里不仅仅关注2个选择，而是回答了我多年来一直使用的4种方法。每个都有其优点和缺点。

1。只有三个字段

只需在每个表中添加三个字段（last action，time_stamp，update_user）并将其调用一天。

优点超级简单。表现很好

缺点您无法报告您没有的数据，因此此结构几乎不会显示任何内容（删除除外）

2。克隆表

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

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

缺点

3。仅限历史表

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

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

缺点您最终会失去维护收益，因为您最终会维护视图，或者您将在整个地方播放获取当前记录的逻辑

4。通用审计表

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

优点易于设置和维护。

缺点

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

  • 执行读写操作时效果不佳。

  • 设置逐行记录报告

    • 很痛苦

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

的摘要

我更喜欢＃2 Clone table方法，因为它似乎最适合我。我遇到了＃1不足的问题，＃4可能是一个严重的噩梦，需要大量工作才能撤消。

相关问题
最新问题