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