我们当前的企业解决方案是由实体框架驱动的ASP.NET MVC应用程序。有一些关于如何挂钩审计变更事件的链接。我对此并不感兴趣。企业数据审计
我对企业级审计架构感兴趣。那些在企业级战斗中受伤的人，你的审计解决方案是什么？您是否在框架中序列化数据库中的对象？你是否设置数据库触发器来审计表？您是否一起使用单独的数据库，以便您的审计增长不会影响您的应用程序数据库？我对这里的尝试和真正的解决方案感兴趣。我知道我们的技术选择（EF）有选项，但我首先对基金会感兴趣。
链接将不胜感激。
我见过几个解决方案，但我最喜欢的一个是很简单的事：
创建审计表是镜像每个源表，添加一些额外的列以跟踪更改的日期和类型（如果您支持，请插入，更新或删除）以及进行更改的用户。删除所有约束和索引（除非您希望进行大量搜索）。
在表更新逻辑内部（我们使用过程，但没有理由不能用OR/M或其他持久层完成，给定相应的钩子），写入源表和源表审计表。
这有很多好处，但最大的一个（在我看来）是不必担心或写所有的代码来管理客户端配对写操作的事务完整性。
虽然我们可以将这些变化挂钩，这意味着我们可以在持久性上做到这一点，但是这里没有存储过程和EF决策。所以基本上这是一个单独的数据库中的应用程序表的镜像？ – RailRhoad 2009-09-17 14:51:29
这是正确的，除了在相同的分贝，这样你会有像“员工”和“EmployeeHistory”旁边的表。 （尽管Craig Stuntz的评论在这里有所说明。）回想起来，我没有理由说它假设存储过程，所以我编辑了那些文本。 – 2009-09-17 16:16:20
这是否意味着一个数据库必须将所有内容写入两次？您是否注意到这样做会对吞吐量产生影响？ – glenatron 2012-09-14 10:31:11
我没有任何链接，但在系统中，我有幸在日常工作中保持在这里。我们有一个审计表，基本上存储以下信息。
表名，PrimaryKeyValue，ModifiedColumn，的OldValue，的NewValue，ChangeUser，更改日期
现在，这个伟大工程的审核速度，在我们的代码，我们有一个自动执行的审计记录的通用接口，但是从一个“审查”的观点，它不是“最快”的方式来获取信息。 （当然，我们还没有真正做过什么需要看审核日志...）
我们最近不得不在我们的企业中解决同样的问题。我们被要求能够恢复到之前的版本。
我们最终审核了业务实体，而不是sql中的表。我们基本上序列化数据库中的记录并跟踪从一个版本到下一个版本所做的更改。这种方法允许我们将以前的版本检索到业务实体中，然后通过调用相同的保存操作进行恢复。这种恢复功能将转移到应用程序责任上，因为它必须在这里解决，否则我们的服务可能需要知道关于参与应用程序的太多细节。 Serivce Operations根据版本，日期，查看历史记录以及审核变更来检索记录。它针对不同的应用程序组和不同的实体（不是数据库中的所有内容都需要进行审计，为什么需要审计）。
然后，我们构建一个轻量级网站，与服务对话并显示所有版本。我们构建了一个机制来显示添加/更新/删除操作以比较不同版本（非常酷的UI表示），这使用户可以查看谁更改了什么以及何时更改。该服务可以发回一个链接到url来查看实体的版本。这使我们的webaps + winform/wpf应用程序能够启动浏览器，以便用户可以看到更改。
也许我可以打包这件事，并提供如果有人有兴趣....
因此，您将EF对象并序列化，然后将它们存储在自己的审计表/数据库中？你如何处理亲子关系？ – glenatron 2012-09-14 10:29:40
也让我再拍重要的注意事项。我们热衷于回头查看应用程序中的旧数据。这是我们认为持久化序列化对象是有帮助的（不仅记录增量）。 – RailRhoad 2009-09-17 14:53:12
一个数据库与多个数据库之间的区别有点人为。数据库可以有多个文件组，表可以有多个分区。您可以像处理多个数据库一样有效地处理单个数据库，并且可以像处理多个表一样处理单个表。 – 2009-09-17 15:02:54