审计记录策略

Question

我正在尝试确定应用程序中审核日志记录的最佳方法。日志的主要原因是报告事件序列（更改）。

我有一个对象层次结构，我需要在后一个日期在该层次结构的任何部分发生变化时创建报告。

我认为我有三个选择：

1. 为每个表创建一个日志，从而匹配对象的层次结构，然后为报告创建一个视图。
2. 展平层次结构并对表格进行反规范化，使报告更容易 - 简单的选择语句。
3. 拥有一个日志表并记录每次更改，使报告更难，但更改更灵活。

我目前倾向于选项1.

Answer 1

即使它已经老了，我也要谈谈这个话题。

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

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

Answer 2

审计日志基本上是按时间顺序列出的事件列表，执行这些事件的人员以及事件是什么。

我认为平面视图会更好，因为它可以轻松订购和查询。所以我更倾向于你的选择＃2 /＃3。

包括交易类型，时间，用户ID，更改内容的说明以及与您的产品相关的其他相关信息。

您还可以随着时间的推移向产品添加内容，您无需不断修改审核日志模块。

Answer 3

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

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

Answer 4

我会选择（2）和（3）：为所有审核条目创建一个表。

平面视图很好，只要额外的工作扁平化不会影响性能。

Answer 5

您可以查看AOP框架来帮助解决这个问题。它允许您在任何/所有方法的开头或结尾注入日志记录功能。如果沿着这条路前进，可能有助于定义存储日志数据的意义。