我提出了一个像下面的例子一样的表：
> 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 | +-----------+------------+--------+------+-------------+
所以问题是：
哪个是更好的设计,一张表可以保留交易的历史记录或每个表的一个字段？ (Pro和cons)
解决方法
Which is a better design,one table that keep the history of
transactions or one field for each table? (Pro and cons)
而不是专注于这两个选择,这是多年来与我合作的4种方法的答案.每个都有其利弊.
只有三个字段
只需将三个字段(最后一个操作,time_stamp,update_user)添加到每个表中,并将其称为一天.
优点超级容易.表现良好
缺点你不能报告你没有的数据,所以这个结构几乎没有告诉你(删除除外)
克隆表
每个表都有一个副本和三个审核字段,每次用户更改审计表插入的记录.
优点表现相当不错.容易创建用户可以挖掘的逐行历史记录.
缺点
>对基表的每次更改都需要对审计表进行相应的更改.
>如果用户不希望逐行记录挖掘,他们想要一个报告,确切地说,它可以在恶意中变得讨厌.看到How can I write a query to extract individual changes from snapshots of data?的答案
3.历史表只
没有基表只有历史表.
这与克隆表基本相同,但现在您必须总是获得当前记录.
优点2,但一切都是插入.较少的维护,然后选项2.
缺点你最终会失去维护收益,因为你最终会维持观点,或者你会把现在的记录逻辑遍布整个地方
通用审计表
该表有四列(表*,Column_name,old_value,new_value)和三个审计字段.
优点易于设置和维护.
缺点
>它的直观,但它占用了很多空间,因为你的old_value和new_value字段必须是nvarchar(max)或等效的,所以它可以接受你的基表中的任何东西.
>读写不好执行.
>设置逐行历史报告的痛苦
>如果记录中有任何工作流审计报告可能变得不平凡.例如,您要求用户只希望在记录上的状态变为“已批准”之后发现更改.即使在备选方案2和3中也是如此,但在通用审计方法中却是一场灾难.
概要
我喜欢#2克隆表的方法,因为它似乎对我最好的工作.我遇到了#1不足的问题,#4可能是一个严重的噩梦,需要大量的工作才能撤消.
