実際にカスケードの削除または制限の削除と、カスケードの更新または制限の更新を実際に使用するタイミングを知りたいです。それらを使用したり、データベースに適用したりするのはかなり混乱しています。
2 に答える
3
外部キー制約でカスケード演算子を使用することは、ちょっと話題になっています。
理論的には、親オブジェクトを削除すると自動的にそのすべての子オブジェクトも削除されることがわかっている場合は、子テーブルと親テーブルの間のリンクで削除をカスケードすることが理にかなっている可能性があります。
「部品」からなる「機械」をイメージしてください。マシンが削除された場合に、そのマシンを構成するすべての部品もデータベースからパージされるというロジックの場合、部品テーブルとマシン テーブルの間の外部キー リンクでカスケード削除オプションを使用できます。
ただし、これは、特にこのオプションでリンクされた一連のテーブル全体を作成する場合は、少し注意が必要です。したがって、多くの開発者は、データベースで定義するよりも、独自のデータ アクセス コードでこれを処理することを好む傾向があります。
更新カスケードは通常、親テーブルの主キーが変更されたときに使用されます。これは、関連するすべての子テーブルと行を更新してその変更を反映させるためです。これは通常、データベース コードの匂いと見なされます。ここでのより良いオプションは、主キーが変更されないようにすることです。これにより、このカスケード更新が不要になります。たとえば、人工的な「代理」キー列をテーブルに導入します。に関連する意味を持つため、更新されることはありません。
それはまったく役に立ちますか？あなたがまだはっきりしていない特定の詳細はありますか？
私の見解は次のとおりです。これは理論的には素晴らしいアイデアですが、ほとんどの開発者はこれを「実際のライブ」で実際に使用することはありません。ほとんどの開発者は、データ アクセス コードでこれを処理することを選択します。これにより、取得するものを完全かつ明示的に制御できます。削除（または更新）されました。
于 2010-09-26T15:03:17.627 に答える
0
marc_sが言うことと同様に..
CASCADEオプションは、トランザクションを延長したり、ロックを増やしたり、リソースを増やしたりする必要がない場合に、子テーブルに「ダミー」の更新を生成することがあることがわかりました。
于 2010-09-26T15:36:10.410 に答える