カスケード削除を避けるべき時期はありますか？

SQL Server 2008には、1対多の関係で他の3つの子テーブルにリンクされているプラ​​イマリテーブルがあります。したがって、プライマリテーブルでカスケード削除を使用して、プライマリテーブルのレコードが削除されると子テーブルのすべてのレコードが削除されるようにすることを検討しています。

1. では、カスケードは正しい選択をここで削除しますか？
2. カスケードdeteleを使用しない場合

私は通常、トリガーまたはを介したカスケード削除（およびその他の自動アクションによるデータのドロップ/損傷の可能性があるアクション）に警戒していますON <something> CASCADE。そのような設備は非常に強力ですが、潜在的に危険です。

• では、カスケードは正しい選択をここで削除しますか？

親レコードが削除されたときに関連レコードを削除します。他のロジックを実装して子が最初に削除されるようにする必要がないため、コードがより簡潔になります。すべてのアクションは暗黙的なトランザクションでラップされるため、何かが子をブロックすると、操作全体が削除され、参照の整合性が維持され、追加のコーディングはほとんどまたはまったく必要ありません。

カスケード削除やその他の「舞台裏」アクションの使用が十分に文書化されていることを確認して、システムの将来の保守担当者がそれを完全に認識できるようにします。

• カスケードdeteleを使用しない場合

あなたが私のように偏執的であるならば、それは使われるべきではありません！考慮すべき重要な点の1つは、現在または将来的にコード/データベースで作業する他の開発者です（ "非表示"の動作の文書化に関する上記のコメントを参照してください）。

経験の浅い人が使用することが私の経験ではかなり一般的であるDELETE再その後、INSERT彼らが本当に望むことである場合は特に、更新行するために、MERGE/のUPSERT操作（更新既存の行と指定したキーを持つ行が存在しない新しいものを作成します）また、DBMSはマージ/アップサートをサポートしていません（または、サポートを認識していません）。カスケードされたアクションがなければ、これは完全に安全です（またはデータの整合性を脅かすときにエラーが発生します）が、参照しているFKがある親テーブルの行に対してこれを行うとON DELETE CASCADE設定すると、関連するデータは最初の削除の結果として削除され、置き換えられません-したがって、データは失われます（削除と後続の挿入が明示的なトランザクションでラップされている場合でも、削除操作でカスケードが発生するわけではありません）トランザクションが後続のステートメントの親テーブルの行を置き換えるかどうかを確認し、カスケードが他の関係シップを介して続行できるかどうかを確認します（例：シニアスーパーバイザーの削除、チームのカスケードによる削除、チームのチームのカスケードによる削除、これらすべての人々の追跡されたすべてのレコードは、カスケードによって削除されます...）。カスケードを有効にしないと、データが静かに失われる代わりに、ここでエラーが発生します。

私は答えはあなたの状況のために理にかなっているかどうかに帰着思い、それが依存します。あなたの状況では、対応する「プライマリ」行が移動した場合に「子」テーブルの行が残ることは理にかなっていますか？子テーブルのデータは、親なしでは無意味ですか？その場合、カスケード削除により参照整合性が適用されます。子行をレコード、過去のアクティビティのアーカイブとして保持することもできます（ただし、この目的のために、これらの行を別のテーブルに書き込む可能性もあります）。

この点を説明するために使用する例は、医師と患者の関係です。1人の医師が多くの患者を持つことができます。医師がいる場合のみ、患者は患者になれます。医師が行く（練習を辞める）場合、残りの患者に何かが発生する必要があります。1つの可能性は、それらがパージされることです。もう1つは、デフォルト値がdoc参照を置き換えるか、メインテーブルから削除して別の場所に配置できるということです。あるいは、活動は発生せず、患者はドキュメントがまだ存在しているかのように、手つかずのままです。何をしたいかによります。

個人的な経験から、データベースの設計について慎重に検討してください。今週私は、どこも指しておらず文字通りスペースを占有していたテーブルで孤立したレコードのパージを実行する必要がありました。

カスケード削除の使用は、テーブルに複数の名前を付けるかどうか（顧客と顧客）など、個人的な好みの問題です。

カスケード削除は絶対に使用しないほうがよいでしょう。一部のデータベース設計では、削除をまったく回避しています。ディスク容量が非常に少ない場合に、データベースからデータを削除する理由はほとんどありません。一部のデータベース設計では、データを物理的に削除するのではなく、追加フィールド「IsDeleted」を設定しています。

データを削除する必要がある場合は、ストアドプロシージャを使用してこれを管理すると、透過性と制御が向上します。アプリケーションは、子から親を削除するストアドプロシージャを実行できます。ビジネス要件が時間の経過とともにどのように変化するかがわからないため、spを使用するとより多くの汎用性が得られます。それは私の2cです。