0

この予見された状況の解決策を策定するのに苦労しています。

TableA には TableB への FK があります。TableC には TableA への FK があります。TableC には TableD への FK があります。

TableA
------
taId
tbId

TableB
------
tbId

TableC
------
tcId
taId
tdId

TableD
------
tdId

簡単な一連のイベント:

  • 1) TableB のレコードに対してカスケード論理削除が発行されます。これにより、TableA のすべての関連レコードが論理削除され、TableC のすべての関連レコードが論理削除されます。
  • 2) その後、TableD のレコードがソフト削除され、再びカスケードされます。TableD のこのレコードは、TableC の FK として保持されていました。ただし、TableC は既に論理削除済みとしてマークされています。
  • 3) 手順 1 の TableB のレコードの復元が要求されます。

    関連するレコードを TableB (つまり、TableA と TableC) の復元されたレコードに復元するときに、手順 2 の TableD のレコードに依存していたレコードを復元しないことを確認するにはどうすればよいですか?テーブル D のレコードに依存していた場合、カスケード方式で復元を制限します (つまり、テーブル C がソフト削除されたレコードと関係があることが判明した場合、テーブル A は復元されません)。

    私が検討したのは、GUID と共にテーブルの一時的な設計を活用することです。各テーブルには、(論理的な削除フラグを除いて) DateDeleted フィールドと GUID フィールド (カスケードのセットを区別するために、カスケードの論理的な削除の各ノードに同じ GUID が割り当てられます) があります。これにより、日付と GUID が共有されるため、カスケード セットを簡単に復元できます。しかし、私が遭遇した問題は、上記で概説したものであり、ソフト削除されたレコードが別のカスケードから削除された状況をどのように処理するかということでした.

    • 4

    1 に答える 1

    2

    レコードはソフト削除されるためTableD、最初のソフト カスケード削除を復元することによって参照整合性が損なわれることを心配する必要はありません。ただし、カスケード リストア ロジックで実行する必要があるのは、ソフト リストアが行われている各テーブルの他の依存関係をテストすることです。

    それ自体がソフト削除された親アイテムへの参照がある場合は、その親アイテムのソフト復元も行う必要があります。

    これを実現する良い方法は、テーブルごとのソフト削除ストアド プロシージャ (またはトリガー) とテーブルごとのソフト リストア ストアド プロシージャ (またはトリガー) を使用することです。これらのプロシージャは、日付/GUID (ソフト削除ビジネス トランザクション ID) を入力パラメーターとして受け取ります。

    各テーブルについて、問題の procs は依存関係が何であるかを知っています。論理的な削除には下流のカスケード依存関係があり、論理的な復元には上流のカスケード依存関係があります。各プロシージャは、独自のテーブルのレコードを削除済みまたは復元済みとしてマークし、カスケード アクションを実行するために必要なプロシージャを呼び出します。

    于 2012-04-11T19:22:40.843 に答える