我在这方面找到了几个讨论线程——但没有什么可以将所有三种机制的比较放在一个线程下。
所以这是我的问题...
我需要审核数据库更改-插入\更新\删除到业务对象。
我可以想到三种方法来做到这一点
1) 数据库触发器
2）休眠拦截器
3) 春季AOP
（这个问题特定于 Spring\Hibernate\RDBMS - 我想这对 java\c# 或 hibernate\nhibernate 是中性的 - 但如果您的答案取决于 C++ 或 Java 或特定的休眠实现 - 请指定）
选择其中一种策略的优缺点是什么？
我不是在询问实现细节。-这是一个设计讨论。
我希望我们可以将其作为社区 wiki 的一部分
我只能谈谈Triggers和NHibernate，因为我对Spring AOP不太了解。
一如既往，这取决于对您来说最重要的是什么。
数据库触发器
NHibernate 拦截器/事件
我知道这与问题不是 100% 相关，但它确实通过新选项增加了价值。
还有另外两种方法可以审核正在发生的事情。
读取事务日志：如果数据库处于完全恢复模式，则有关 INSERT、UPDATE、DELETE 和 DDL 语句的所有详细信息都将记录到事务日志中。
问题是它阅读起来非常复杂，因为它本身不受支持，并且您需要第三方事务日志阅读器，例如ApexSQL Log或SQL Log Rescue（后者是免费的，但仅支持 sql 2000）。
这种方法的优点是，除了将数据库置于完全恢复模式之外，您实际上不必进行任何更改。
SQL Server 跟踪：跟踪将捕获跟踪文件中的所有内容，包括某些合规性方案也可能需要的 select 语句。缺点是跟踪是需要解析和组织的文本文件。
我想不出任何不使用数据库触发器来审计对数据库的更改的充分理由。插入、更新和删除可能会从各种来源命中数据库——触发器会捕获所有这些；休眠等不会。
我认为当您考虑审计时，您需要考虑它的用途。首先，它是记录谁更改了什么以及更改了什么，这样您就可以撤消错误的更改，您可以识别系统的问题（我们可以看到几个不同的应用程序中的哪个导致了更改，这有助于快速识别哪个应用程序损坏了）这样您就可以确定是谁进行了更改。在检测欺诈方面，最后一个可能非常关键。如果您从用户界面做所有事情，您将永远不会看到用户进行欺诈，他们更改后端的数据以给自己写一张支票。如果您从界面执行所有操作，则可能您必须在表级别设置权限，从而为欺诈打开大门。如果你从界面做所有事情，你会' 不知道哪个心怀不满的员工删除了整个用户表以获取纯粹的烦恼值。如果您从前端做所有事情，您将不知道哪个不称职的 dba 不小心将所有客户订单更新到同一客户。除了触发器之外，我不支持使用任何东西进行审计，因为您首先失去了为什么需要审计的很大一部分。
使用 Hibernate 拦截器执行审计日志存在严重缺陷。我对推荐这种方法的博客数量感到震惊，但没有指出它最明显的缺陷——拦截器必须使用新事务来记录审计。这意味着您可以成功保存主要交易，但系统崩溃无法记录审计交易！
我现在偶然发现的一个老问题。还有一个可用的选项，那就是 Envers，从 3.6 版开始，它与休眠一起可用。