2

私は従業員と対応する従業員履歴テーブルを持っています。

どちらのテーブルも同じ構造です。履歴テーブルは、一定期間にわたって従業員に加えられた履歴変更を追跡するために使用されます。

ここで、従業員に加えられた変更に元に戻す機能を追加する必要があります。

例: 8 月 1 日に従業員の役職が変更されました。これで、Employee テーブルの従業員の役職が更新され、employee_history テーブルに対応する履歴レコードが挿入されます。

ここで、この変更を元に戻す必要があります。従業員の編集ページには、日付ごとに従業員に加えられた変更のリストがあり、その横に元に戻すボタンがあります。

元に戻すをクリックすると、Employee テーブルの変更が以前の値に戻されます。また、タイトルが変更されたという履歴テーブルのレコードも削除する必要があると思います。

また、従業員テーブルへの変更を元に戻す、つまりタイトルを前のタイトルに戻すと、履歴テーブルへの挿入が発生しますが、これは望ましくありません。

これを行う最善の方法が何であるかはわかりません。

どんな提案も役に立ちます。

4

3 に答える 3

2

「永続的な」取り消し(アプリケーションの再起動/セッションのタイムアウト後も存続する)を実装する場合は、DBスキーマ幅timestampフィールドを拡張して、最後のエントリを削除するか、適切な以前のエントリに置き換えることを検討する必要があります。

「ライト」バージョンは、スタックを使用して、元の値と新しい値を含む最後のインタラクションを格納します。もちろん、セッションの無効化でスタックを永続化して、両方のアプローチを組み合わせることができます。これはあなたが実際にやっていることのようです。

このソリューションを拡張するには、変更ごとにSQL移行スクリプトを作成して保存またはエクスポートし、変更を記録し、可能であれば反対のアクションを実行します。したがって、アプリケーションインスタンスと環境の間でスクリプトを転送することもでき、DB状態の完全な「再生可能性」が得られます。

tl;dr-すでに優れたソリューションを実装しているようです

于 2012-08-01T13:54:07.237 に答える
0

トランザクションのロールバック機能を使用できる可能性があります。

于 2012-08-01T13:53:02.637 に答える
0

元に戻す操作を実行していて、履歴データを書き込まない間は、トリガー/履歴ロジックを停止するように指示するフラグを使用することをお勧めします。

通常、これは、履歴テーブルからのシリアライザー クラスのフィードと従業員データの復元、および後で履歴エントリのクリーンアップ/履歴のロック解除によって行われます。

于 2012-08-01T13:45:43.780 に答える