MySQL監査テーブル：hibernate-enversとトリガー

Question

私はauditのuserテーブルを持っています。私はを使用しています。同じものについてはです。これは私の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; 
} 

私は休止状態-enverのパフォーマンスについてはよく分かりません。休止状態になる前は、監査証跡を保持するためにトリガーを使用していました。私はエンバーを続けるか、トリガーに戻るべきですか？

PS：パフォーマンスに基づいて比較したい。文字通り、エンバーを使用する理由は余分な努力を必要としないので、努力/開発の際には明らかな選択です。

Answer 1

必要に応じてジョブを実行する場合は、続行します。後でそれが何らかの基準を満たしていないとわかった場合は、いつでもそれを変更したりパフォーマンスの問題を報告したりできます。

ご質問には、このようなベンチマークは存在しません。とにかくそれが誤解を招く可能性が最も高いので、もしそうしたら、私はそのようなベンチマークに疲れているだろう。

通常、開発者は、あなたが非常に単純であるように監査トリガーを設計します。言い換えれば、行コピー機として動作し、それ以外は何もしません。挿入、更新、または削除中に、テーブルのデータのスナップショットを別のテーブルにコピーするだけです。完了しました。

明らかに、Enversはエンティティ間の監査された関係の概念をサポートすることでこれをさらに遠ざけます。また、変更時に環境に関する属性を提供することで、誰が何を変更したのか、変更した理由などを追跡することができます。

Enversの最大の利点は、フレームワークの仕事。あなたが指摘したように、エンティティ関係の最も複雑なものであっても、それを簡単に、しかも簡単に管理できます。

データベーストリガーがクライアントソフトウェアベースのソリューションと同等またはそれ以上の性能を発揮する使用例があると確信しています。その場合、ネットワーク遅延はなく、トリガーは独自のデータベースオプションを使用して、フレームワークがより多くのクロスプラットフォームのデータベースに依存しない機能を使用するパフォーマンスを向上させることもできます。

最後に、表示されたエンティティは超シンプルなようです。文字通りEnversがそのエンティティを処理するためのオーバーヘッドはほとんどありません。リレーションシップはありません。したがって、それぞれの行の変更とリビジョンエンティティのための簡単な挿入があります。

より複雑なエンティティオブジェクトグラフを継承と複雑な関連付けだけで使用するEnversの実装があります。