实施审计跟踪 - Spring AOP vs.Hibernate Interceptor vs DB Trigger
我发现了一些关于此的讨论线程，但没有任何内容可以在一个线程下对所有三种机制进行比较。
所以这是我的问题...
我需要审核数据库更改 - 对业务对象的插入\更新\删除。
我可以想到三种方法来做到这一点
1）DB触发器
2）Hibernate拦截器
3）Spring AOP
（这个问题特定于Spring\Hibernate\RDBMS-我想这对java\c#或hibernate\nhibernate是中性的-但是如果您的答案取决于 C++ 或 Java 或 hibernate 的具体实现 - 请注明）
选择这些策略之一的优点和缺点是什么？
我不是要求实现细节。-这是一个设计讨论。
我希望我们可以将其作为社区维基的一部分
I found couple of discussion threads on this- but nothing which brought a comparison of all three mechanism under one thread.
So here is my question...
I need to audit DB changes- insert\updates\deletes to business objects.
I can think of three ways to do this
1) DB Triggers
2) Hibernate interceptors
3) Spring AOP
(This question is specific to a Spring\Hibernate\RDBMS- I guess this is neutral to java\c# or hibernate\nhibernate- but if your answer is dependent upon C++ or Java or specific implementation of hibernate- please specify)
What are the pros and cons of selecting one of these strategies ?
I am not asking for implementation details.-This is a design discussion.
I am hoping we can make this as a part of community wiki
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
我知道这与问题并不 100% 相关，但它确实通过新选项增加了价值。
您还有两种方法可以审核正在发生的情况。
读取事务日志：如果数据库处于完全恢复模式，则有关 INSERT、UPDATE、DELETE 和 DDL 语句的所有详细信息都会记录到事务日志中。
问题是它的读取非常复杂，因为它本身不支持，并且您需要第三方事务日志阅读器，例如 ApexSQL 日志 或 SQL 日志救援（后者是免费的，但仅支持sql 2000）。
此方法的优点是，除了将数据库置于完全恢复模式之外，您实际上不必进行任何更改。
SQL Server 跟踪：跟踪将捕获跟踪文件中的所有内容，包括某些合规性场景也可能需要的 select 语句。 缺点是跟踪是需要解析和组织的文本文件。
I understand this is not 100% related to the question but it does add value with new options.
There are two more ways you can audit what’s going on.
Reading transaction log: If database is in full recovery mode then all details about INSERT, UPDATE, DELETE and DDL statements are logged into transaction log.
Problem is that it’s very complex to read because it’s not natively supported and that you’ll need a third party transaction log reader such as ApexSQL Log or SQL Log Rescue (the latter one is free but only supports sql 2000).
Advantage of this method is that you literally don’t have to make any changes except to put your database in full recovery mode.
SQL Server traces: Traces will capture everything in trace files including select statements which also may be needed for some compliance scenarios. The downside is that traces are text files that need to be parsed and organized.
我想不出不使用数据库触发器来审计数据库更改的任何充分理由。 插入、更新和删除可能会从各种来源访问数据库 - 触发器将捕获所有这些； Hibernate等不会。
I can't think of any good reason for not using database triggers to audit changes to the database. Inserts, updates and deletes can potentially hit the database from various sources - triggers will catch all these; Hibernate etc. will not.
我认为当你考虑审计时，你需要考虑它的用途。 首先，它是记录谁更改了什么以及更改了什么，以便您可以撤销错误的更改，您可以识别系统问题（我们可以看到几个不同的应用程序中的哪一个导致了更改，这有助于快速识别哪个应用程序被破坏）这样您就可以确定是谁做出了更改。 在检测欺诈时，最后一个可能非常关键。 如果您从用户界面执行所有操作，您将永远不会看到用户更改后端数据以给自己写支票来进行欺诈。 如果您通过界面执行所有操作，则可能必须在表格级别设置权限，从而为欺诈打开了大门。 如果您从界面执行所有操作，您将不知道哪个心怀不满的员工为了纯粹的烦恼值而删除了整个用户表。 如果您从前端完成所有操作，您将不知道哪个无能的 dba 意外地将所有客户订单更新到同一客户。 我不支持使用除触发器之外的任何内容进行审核，因为您一开始就失去了大部分需要审核的原因。
I tink when you consider auditing, you need to consider what it is for. First, it is to havea record of who changed what and what changed so you can back out bad changes, you can identify problems with the system (we can see which of several differnt applications casued the change which helps identify quickly which one is broken) and so you can identify who made the change. The last can be really critical when it comes to detecting fraud. If you do everything from the user interface, you will never see the user committing fraud who changes the data in the backend to write himself a check. If you do everything from the interface, likely you have to have permissions set at the tabel level, thus opening the door for fraud to begin with. If you do everything from the interface you won't know which disgruntled employee deleted the entire user table for the pure annoyance value. If you do everything from the front end you won't know which incompetent dba accidentally updated all customer orders to the same customer. I can't support using anything except triggers for auditing as you lose a good part of why you need auditing in the first place.
使用 Hibernate 拦截器执行审核日志存在严重缺陷。 我对推荐这种方法的博客数量感到震惊，但没有指出其最明显的缺陷 - 拦截器必须使用新事务来记录审计。 这意味着您可以成功保存主交易并发生系统崩溃而无法记录审计交易！
Using Hibernate interceptors to perform Audit logs is deeply flawed. I'm stunned by the number of blogs that recommend this method without pointing out its most obvious flaw - the interceptor HAS to use a new transaction to record the audit. Which means you could successfully save the main transaction and have a system crash that fails to record the audit transaction!
我现在偶然遇到的一个老问题。还有一个可用的选项，那就是 Envers，它从 3.6 版开始与 hibernate 一起可用。
an old question that i chanced upon now.There is one more option available and that is Envers which is available along with hibernate starting from ver 3.6 onwards..
我只能谈论触发器和NHibernate，因为我对Spring AOP了解不够。
一如既往，这取决于什么对您来说最重要。
数据库触发器
NHibernate 拦截器/事件
I only can talk about Triggers and NHibernate, because I don't know enought abou tSpring AOP.
It depends on, as always, what is most important for you.
DB triggers
NHibernate interceptors / events