我正在尝试确定在我的应用程序中审计日志记录的最佳方法。日志的主要原因是报告事件的顺序（更改）。
我有一个对象层次结构，当该层次结构的任何部分发生变化时，我需要在以后创建报告。
我认为我有三个选择：
- 每个表都有一个日志，因此匹配对象的层次结构，然后为报告创建一个视图。
- 扁平化层次结构和去规范化表格，使报告更容易 - 简单的选择语句。
- 拥有一个日志表并记录每个更改，这使得报告更难但更灵活地更改更改。
我目前倾向于选项1。
3219 次
5 回答
10
我必须谈谈这个话题，即使它已经过时了。
只有一个审计表通常是一个糟糕的主意，因为当一切都命中该表时，您将在数据库中产生锁定问题。为每个表使用单独的审计表。
让应用程序进行审计也是一个糟糕的主意。审计必须在数据库级别进行，否则您可能会丢失一些信息。数据不仅仅来自大多数数据库中的应用程序；当您需要将所有 10,000,000 种产品的价格提高 10% 时，没有人会从用户界面一次更改所有产品的价格。审计应该捕捉所有的变化，而不仅仅是其中的一部分。这应该在大多数数据库中的触发器中完成（SQL Server 2008 具有内置的审计功能）。一些最糟糕的潜在变化（员工进行欺诈或想要恶意破坏数据）也经常来自应用程序以外的地方，特别是如果您允许用户访问表级访问（您不应该在任何财务数据库或包含个人信息）。从应用程序进行审计不会捕捉到这一点。开发人员经常忘记，在保护他们的数据时，外部来源并不是唯一的威胁。
于 2010-01-08T23:06:30.037 回答
5
审核日志基本上是按时间顺序排列的已发生事件、执行这些事件的人员以及事件内容的列表。
我认为平面视图会更好，因为它可以轻松订购和查询。所以我更倾向于你的选项#2/#3。
包括交易类型、时间、用户 ID、更改内容的描述以及与您的产品相关的其他相关信息。
随着时间的推移，您还可以将内容添加到您的产品中，而无需不断修改审核日志模块。
于 2009-03-06T00:01:01.390 回答
3
如果出于审计目的，我将使用真正的仅附加介质，而不是同一数据库中的表/表。
您建议将其用于更改历史记录-在这种情况下，我将重组您的应用程序/数据库以首先记录实际事件，而不仅仅是当前状态。
于 2009-03-06T00:15:07.457 回答
1
我会选择（2）和（3）：为所有审计条目创建一个表。
平面视图是好的，前提是额外的工作压平不会影响性能。
于 2009-03-06T00:33:50.267 回答
0
您可以查看 AOP 框架来帮助解决此问题。它将允许您在任何/所有方法的开头或结尾注入日志记录功能。如果你走这条路，它可能有助于定义存储日志数据的意义。
于 2009-03-06T00:39:16.943 回答