我正在尝试创建一些功能,以保留给定用户表单中的数据如何随时间变化的审计跟踪,并在该页面的底部提供带日期的审计。例如:
02/04/09 21:49 名称从“Tom”更改为“Chris”。
我这样做的方法是将数据以其当前格式存储在会话中,然后在保存时检查所存储的数据是否存在任何差异。如果有,我会将最新编辑之前的数据存储在名为历史记录的表中,并将新值存储在当前用户表中。
这是最好的方法吗?
我不确定是否存在一种“最佳方法”,需要考虑很多变量,包括您的发展道路有多远。
在经历了基于代码和数据库触发的审计解决方案之后,我在下面列出了一些评论;我希望您能看到您现在所处的位置(在发展方面)可能会影响这些问题:
- 如果您需要映射更改数据的用户(您通常会这样做),那么数据库触发器将需要以某种方式获取此信息。并非不可能,但需要更多工作和多种方法来解决此问题(数据库用户执行查询、每个表中的公共用户列等)
- 如果您使用数据库触发器并且依赖于从查询返回的受影响行数,那么您的审核触发器需要将其关闭,或者修改现有代码以考虑它们。
- 恕我直言,数据库触发器提供了更高的安全性,并提供了更简单的自动化审计路径,但是它们并不是万无一失的,因为任何具有适当访问权限的人都可以禁用触发器,修改数据,然后再次启用它们。换句话说,确保您的数据库安全访问权限严格。
- 使用单个历史表并不是一个坏方法,尽管如果您要审计多个表的历史记录,特别是在重建审计跟踪时,您将需要做更多工作(以及要存储数据)。如果有许多表尝试写入一个审计表,您还必须考虑锁定问题。
- 另一种选择是为每个表建立一个审计历史记录表。您只需要审计表中的每一列都可以为空,并存储操作(插入/更新/删除)的日期和时间以及与该操作关联的用户。
- 如果您选择单表选项,除非您有很多时间花在这上面,否则不要太花哨地尝试仅审核更新或删除,尽管避免插入可能很诱人(因为大多数应用程序都这样做比更新或删除更频繁),重建审计历史记录需要相当多的工作。
- 如果您的服务器或数据跨越多个时区,请考虑使用适当的日期时间类型来存储和重建时间线,即以 UTC 格式存储审核事件日期并包含时区偏移量。
- 这些审计表可能会变得很大,因此如果它们开始影响性能,请制定策略。选项包括将表分区到不同的磁盘上、归档等。基本上现在就考虑这个,而不是当它成为问题时:)
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)