我们当前的企业解决方案是由实体框架驱动的 ASP.NET MVC 应用程序。有几个关于如何挂钩更改事件以进行审计的链接。我对这个不是很感兴趣。
我对企业级审计架构感兴趣。你们这些企业级战伤的人，你们的审计解决方案是什么？您是否在框架中序列化数据库中的对象。您是否设置数据库触发器来审计表？您是否一起使用单独的数据库，以便您的审计增长不会影响您的应用程序数据库？我对这里经过验证的真实解决方案感兴趣。我知道我们的技术选择 (EF) 有多种选择，但我首先对基础感兴趣。
链接将不胜感激。
【问题讨论】：
我没有任何链接，但在我很高兴在日常工作中维护的系统中。我们有一个单独的审计表，它基本上存储了以下信息。
TableName、PrimaryKeyValue、ModifiedColumn、OldValue、NewValue、ChangeUser、变更日期
现在，这对审计速度很有用，在我们的代码中，我们有一个通用接口用于自动实现审计日志记录，但从“审查”的角度来看，这并不是获取信息的“最快”方式退出。 （当然我们实际上并没有做任何需要查看审计日志的事情......）
【讨论】：
我们最近不得不在我们的企业中解决同样的问题。我们也被要求能够恢复到以前的版本。
我们最终审计的是业务实体而不是 sql 中的表。我们基本上序列化数据库中的记录并跟踪从一个版本到下一个版本所做的更改。这种方法允许我们将以前的版本检索到业务实体中，然后通过调用相同的保存操作来恢复。这个恢复的功能将转移到应用程序的责任上，因为它必须在这里解决，否则我们的服务可能需要了解有关参与应用程序的太多细节。提供了按版本、按日期、查看历史记录以及审计更改的服务操作来检索记录。对于不同的应用程序组和不同的实体，它是一种选择加入的方法（并非数据库中的所有内容都需要审计，所以为什么要这样做）。
然后，我们构建一个轻量级网站，该网站与服务对话并可以显示所有版本。我们建立了一种机制来显示添加/更新/删除以在版本之间进行比较（非常酷的 ui 表示），这允许用户查看谁更改了什么以及何时更改。该服务可以发回指向该 url 的链接以查看实体的版本。这允许我们的 webaps + winform/wpf 应用程序启动浏览器，以便用户可以看到更改。
也许我可以把这个打包，如果有人感兴趣，可以提供....
【讨论】：
我见过几种解决方案，但我最喜欢的是简单性本身：
创建镜像每个源表的审计表，添加一些额外的列来跟踪更改的日期和类型（如果您支持，则插入、更新或删除）以及进行更改的用户。删除所有约束和索引（除非您希望进行大量搜索）。
在表更新逻辑内部（我们使用了过程，但没有理由不能使用 OR/M 或其他持久层来完成，给定适当的挂钩），写入源表和审计表。
这有很多好处，但最大的好处（在我看来）是不必担心或编写所有代码来管理客户端中配对写入操作的事务完整性。
【讨论】：