複数のオブジェクトに対して CRUD を実行する GWT/Java/Hibernate/MySQL アプリケーション (ただし、任意の Web パターンが有効であると思います) があります。各オブジェクトは、データベース内のテーブルに格納されます。アクションロガーを実装したい。たとえば、オブジェクト AI の場合、誰がそれを作成して変更したかを知りたいとします。ユーザー B の場合、彼はどのようなアクションを実行したかを知りたいとします。
私の考えは、UserId、ObjectId、ActionName を格納する History テーブルを持つことです。UserId と ObjectId は外部キーです。私は正しい軌道に乗っていますか？
If only changes to specific fields, e.g., something like status in a users table, should be tracked, I would use a user_status_histories table being referenced from the users table via foreign key. The user_status_histories table would contain fields such as current_status, date and something like admin_who_modified_the_status.
Whenever a status change is made, a new record would be inserted into the user_status_histories table. This would allow easy querying of all status changes.
Of course, querying a user would then require a (LEFT or INNER) JOIN with the user_status_histories table in order to get the last record (= the current status).
Depending on your needs, you might think of a current_status field in the users table (besides the status serving as foreign key) for fast access, which would be maintained parallel to the user_status_histories table.
これも正しい方向だと思います。
ただし、トラフィックの多いアプリケーションでは、このログがオーバーヘッドになる可能性があることに注意してください。この場合、次のことをお勧めします-A.この「アクションロギング」に休止状態を使用しないでください-休止状態は「ほとんど読み取りDB」のパフォーマンスが優れています
B.アクションロギングの「ほとんど書き込み」シナリオでより優れたDBを検討してくださいテーブル。
このための NoSQL ソリューションを探すことができます。
C. そのような NoSQL DB を使用しているが、ログ アクションをリレーショナル DB に保持したい場合は、たとえば 1 日に 1 回実行されるオフライン プロセスを用意し、「アクション ログ DB」にクエリを実行して、それをリレーショナル DB。
D. システムが一部のアクション ログを失う可能性がある場合は、プロデューサー/コンシューマー パターンの使用を検討してください (たとえば、プロデューサー スレッドとコンシューマー スレッド間でキューを使用する)。それらを非同期に。
E. さらに、このようなロギング テーブルは時間内にオーバーフラッディングする可能性があり、クエリに時間がかかることを忘れないでください。
これらの問題については、次のことを考慮してください
。毎日、非常に古いログ (たとえば、1 か月以上前) を削除するか、「バックアップ」テーブルに移動します。
E.2 アクション ログ クエリに主に使用するいくつかのフィールドにインデックスを付けます (たとえば、action_type フィールドなど)。
はい、そうです。もう 1 つの非常によく似たフレームワークは、取り消しとやり直しをサポートするフレームワークです。これらのフレームワークは、ユーザー アクションを追跡し、ユーザー アクションの前の状態に状態を復元する追加機能を備えています。