これまでに見たものの要約：
- カスケードをまったく嫌う人もいます。
カスケード削除
- カスケード削除は、関係のセマンティクスに排他的な"が含まれる可能性がある場合に意味があります "説明。たとえば、OrderLineレコードはその親注文の一部であり、OrderLineが複数の注文間で共有されることはありません。注文が消えた場合は、OrderLineも同様になり、注文のない行が問題になります。
- カスケード削除の標準的な例は、SomeObjectとSomeObjectItemsです。ここでは、対応するメインレコードがなくても、アイテムレコードが存在することは意味がありません。
- すべきではありません 履歴を保持する場合、または削除されたビット列のみを1 / trueに設定する「ソフト/論理削除」を使用する場合は、カスケード削除を使用します。
カスケード更新
- カスケード更新は、テーブル全体で代理キー（ID /自動インクリメント列）ではなく実際のキーを使用する場合に意味があります。
- Cascade Updateの標準的な例は、変更可能なユーザー名など、変更可能な外部キーがある場合です。
- すべきではありません Identity/autoincrement列であるキーでCascadeUpdateを使用します。
- カスケード更新は、一意の制約と組み合わせて使用するのが最適です。
カスケードを使用する場合
- 操作をカスケードする前に、ユーザーからさらに強力な確認を取り戻すこともできますが、それはアプリケーションによって異なります。
- 外部キーの設定を間違えると、カスケードによって問題が発生する可能性があります。しかし、それを正しく行えば大丈夫なはずです。
- 完全に理解する前にカスケードを使用することは賢明ではありません。ただし、これは便利な機能であるため、時間をかけて理解する価値があります。