审计日志策略

只有一个审计表通常不是一个好主意,因为当所有内容都命中该表时,会在数据库中产生锁定问题。对每个表使用单独的审核表。

让应用程序进行审计也是一个糟糕的想法。审计必须在数据库级别进行,否则可能会丢失一些信息。数据不会仅从大多数数据库中的应用程序中更改;当你需要将所有10000000件产品的价格提高10%时,没有人会从用户界面一次一件地改变所有产品的价格。审核应该捕获所有更改,而不仅仅是其中的一部分。这应该在大多数数据库中的触发器中完成(SQLServer2008具有内置的审核功能)。一些最糟糕的潜在更改(员工欺诈或恶意破坏数据)也经常来自应用程序以外的其他地方,特别是如果您允许用户进行表级访问(您不应该在任何财务数据库或包含个人信息的数据库中这样做)。来自应用程序的审核无法捕获此信息。开发人员常常忘记,在保护他们的数据时,外部资源并不是唯一的威胁。

审计日志基本上是按时间顺序列出发生的事件、执行这些事件的人以及事件的内容。

我认为平面视图会更好,因为它可以很容易地排序和查询。所以我更倾向于你的选择#2/#3。

包括事务类型、时间、用户id、更改内容的描述以及其他与产品相关的信息。

如果出于审计目的,我会使用一个真正的只附加的媒体,而不是同一数据库中的一个表。

您建议这是为了更改历史记录——在这种情况下,我会重新构造您的应用程序/db,以便首先记录实际事件,而不仅仅是当前状态。

我将使用(2)和(3):为所有审计条目创建一个表。

如果展开额外的工作不会影响性能,则展开视图是好的。

您可以研究AOP框架来帮助实现这一点。它允许您在任何/所有方法的开头或结尾注入日志功能。如果沿着这条路走下去,它可能有助于定义存储日志数据的意义。