问审计日志策略

EN

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

我认为平面观会更好，因为它可以很容易地订购和查询。所以我更倾向于你的选择2/3。

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

随着时间的推移，您也可以将内容添加到您的产品中，您不需要不断地修改您的审计日志模块。

尽管这个话题很古老，但我还是得谈一谈。

只有一个审计表通常是一个糟糕的主意，因为当所有的东西都击中该表时，您将在数据库中创建锁定问题。对每个表使用单独的审核表。

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

如果是为了审计目的，我将使用真正的仅附加介质，而不是同一个db中的表/表。

您建议它用于更改历史记录--在这种情况下，我将重构您的应用程序/db，以便首先记录实际事件，而不仅仅是当前状态。