Question

我有一个user表，我想audit。我正在使用 hibernate-envers 。这就是我的user类的样子：

@Audited
@Entity
@Table(name = "user")
public class User {

    @Id
    @Column(name = "id")
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private int id;

    @Column(name = "phone_number")
    private String phoneNumber;

    @Column(name = "profile_pic")
    private String profilePic;
}

我不确定hibernate-enver的性能。在hibernate-envers之前，我使用触发器来保持审计跟踪。我应该继续使用envers还是切换回触发器？

PS：我想根据性能进行比较。因为使用envers的原因不需要任何额外的努力，所以努力/开发时间明智，这是显而易见的选择。

Answer 1

如果符合需要并完成工作，那么继续。如果您发现它的性能达不到某些标准，您可以随时更改它或报告性能问题，我可以查看它。

对于您的问题，不存在此类基准。如果确实如此，我甚至会厌倦这样的基准，因为它最有可能产生误导。

通常，开发人员设计的审计触发器就像您所描述的非常简单。换句话说，它们可以作为行复印机而不是其他任何东西。在插入，更新或删除期间，它们只是将表中数据的快照复制到另一个表中。完成。

显然，Envers通过支持实体之间审计关系的概念来进一步发展。它还允许您在更改期间提供有关环境的属性，以便您可以跟踪诸如更改内容，更改原因以及更改的内容等。

Envers的最大优势实际上是实现这样一个框架所需的努力。正如您所指出的那样，它非常轻松，即使在最复杂的实体关系中，它也非常容易管理它们。

我确信在某些情况下，数据库触发器的性能与基于客户端软件的任何解决方案相同或更好。在这种情况下，您没有网络延迟，触发器也可以使用专有数据库选项来提高性能 - 因为框架将使用更多跨平台数据库无关的功能。

最后，您展示的实体似乎非常简单。对于Envers来说，处理该实体几乎没有任何开销。没有关系，因此它将是每个User行更改的简单插入和修订实体的一个插入。

有些Envers的实现使用了更为复杂的实体对象图，其继承和复杂的关联就好了。

MySQL审计表：hibernate-envers vs Triggers

1 个答案: