11

階層に3つのテーブルがあるとしましょう。

TableA -> TableB -> TableC

TableCと外部キー関係がありTableB、とTableB外部キー関係がありTableAます。

のレコードをTableA削除すると、階層を介してカスケード削除する必要があります。使用ON DELETE CASCADEすると問題なく動作します。

INSTEAD OFただし、にトリガーを設定する必要があるとしましょうTableC。私の理解でINSTEAD OFは、削除カスケードが行われているテーブルにトリガーを設定することはできません。MSDNから取得：

INSTEAD OFトリガーの場合、DELETEオプションは、DELETEのカスケードアクションを指定する参照関係を持つテーブルでは許可されていません。

カスケード削除をオフTableB->TableCにする必要がある場合は、INSTEAD OFトリガーを使用して参照整合性を適用する必要があります。その後、。で同じ問題が発生しTableB->TableAます。これは単純な例ですが、カスケードパスがはるかに大きいことを想像してください。長いカスケードパス全体で雪だるま式になりやすいようです。

では、このシナリオに対処するためのベストプラクティスは何ですか？

4

2 に答える 2

4

INSTEAD OFトリガーを使用する必要があり、AFTERトリガーがオプションではない場合、最善のアプローチは、a）スキーマを厳密に制御して、b）INSTEADOFトリガーを通常の方法でスクリプト化してCASCADEDELETEなどを実装することです。必要なその他の操作。

以前と同じようにFK制約を作成しますが、カスケード動作はありません。FK名では、いくつかの規則を使用して、どのような種類のカスケード動作とカスタム動作が発生するかを示します。例：

  • FK_UC_DC_Table1_Table2-カスケードの更新、カスケードの削除
  • FK_UC_DN_Table1_Table3-カスケードを更新し、セットnullを削除します

意味のあるものは何でも使用しますが、FKを作成します。FKはコード生成に役立つメタデータであり、FK名を使用してコードジェネレーターのディレクティブを記録できます。

次に、さらに一歩進んで、これらのテーブルを独自のスキーマに分離します。これらは他のテーブルと同じように動作することはなく、コード生成をテストして微調整すると、最初はバグが多くなります。これらすべてを隔離し、共通のコンテナで簡単に識別できるようにするのが最善です。

専用スキーマは、データを変更するすべての人に、さまざまなルールと動作が適用されることも通知します。

于 2012-06-03T15:29:34.940 に答える
3

標準のベストプラクティスは、テーブルではなくビューでINSTEADOFトリガーを定義することです。

FKの更新/削除でトリガーを使用する必要がある場合は、常に実行されるため、AFTERを使用するのが最適です。

カスケードアクションをキャンセルしてFKを保持したい場合は、FKアクションをNOACTIONに設定するだけです。

于 2012-06-04T13:20:39.940 に答える