这是创建审计跟踪的最佳方法吗？

我正在尝试创建一些功能,以便对给定用户表单中的数据如何随时间变化进行审计跟踪,并在该页面的底部进行过时的审计.例如:

02/04/09 21:49名称由"Tom"改为"Chris".

我这样做是通过在会话中以数据的当前格式存储数据,然后在保存时检查存储的数据是否存在任何差异.如果有,我将数据存储在名为history的表中最新编辑之前的数据,并将新值存储在当前用户表中.

这是最好的方法吗？

我不确定是否有一个"最佳方法",需要考虑很多变量,包括你的开发路径有多远.

通过基于代码和数据库触发器的审计解决方案,我在下面列出了一些评论; 我希望你能看到你现在所处的位置(在开发方面)会影响这些问题:

如果您需要映射更改数据的用户(您通常会这样做),那么db触发器将需要以某种方式获取此信息.并非不可能,但需要更多的工作和几种方法(db用户执行查询,每个表中的公共用户列等)

如果您使用数据库触发器并依赖于从查询返回的受影响的行计数,那么您的审计触发器需要关闭它,或者修改现有代码以解释它们.

IMHO数据库触发器提供更多安全性,并提供更简单的审计自动化路径,但它们并非万无一失,因为任何具有适当访问权限的人都可以禁用触发器,修改数据然后再次启用它们.换句话说,确保您的数据库安全访问权限很紧.

拥有一个历史记录表并不是一个糟糕的方法,但如果您要审计多个表的历史记录,尤其是在重建审计跟踪时,您将有更多工作要做(以及要存储的数据).如果有许多表试图写入一个审计表,您还必须考虑锁定问题.

拥有每个表的审计历史记录表是另一种选择.您只需要审计表中的每一列都可以为空,以及存储操作的日期和时间(插入/更新/删除)以及与操作关联的用户.

如果你选择单表选项,除非你有足够的时间花在这上面,不要过于花哨试图只审计更新或删除,尽管它可能很容易避免插入(因为大多数应用程序都这样做)通常比更新或删除更重要,重建审计历史需要相当多的工作.

如果您的服务器或数据跨越多个时区,则考虑使用适当的日期时间类型来存储和重建时间线,即以UTC格式存储审计事件日期以及包括时区偏移.

这些审计表可能会变得很大,因此如果它们开始影响性能,请制定策略.选项包括将表分区到不同的光盘上,存档等等.现在基本上考虑这个,而不是当它成为问题时:)

一个建议; 这在数据库触发器中相对容易.在这种情况下,您永远不必担心运行更新的代码是否记得添加历史记录.