回答。

関連するテーブル（例："注文"と"顧客"）は、リレーショナルデータベースが登場した初期から存在していましたが、初期の段階では整合性の管理がプログラムロジックを通じて手動で実装される必要がありました。SQLの進展に伴い、組み込みの制約（FOREIGN KEY）と自動アクション（CASCADE）が登場しました。

問題の歴史：

初期のデータベースでは、"孤立"したレコード（例：存在しない顧客の注文）が生まれないように、整合性を維持するメカニズムが必要でした。FOREIGN KEYは標準となり、CASCADEオプションは削除や変更時の同期を自動化しました。

問題：

CASCADEアクションがないと、主要テーブルの行を削除または更新するとエラーや"孤立した"データが発生します。このタスクをアプリケーションに委ねると、保守の複雑さや大量操作時のインシデントリスクが高まります。CASCADEアクションの不適切な使用は、連鎖的な削除やビジネスロジックの破壊を引き起こす可能性があります。

解決策：

ON DELETE CASCADEおよびON UPDATE CASCADEを使用したFOREIGN KEYの適用により、整合性を自動的に維持し、関連するテーブルを正しく同期できます。複雑なシナリオでは（例えば、削除だけでなくアクションをログする必要がある場合）、トリガーを使用します。

コード例：

CREATE TABLE Customers (
  CustomerID INT PRIMARY KEY,
  Name NVARCHAR(100)
);

CREATE TABLE Orders (
  OrderID INT PRIMARY KEY,
  CustomerID INT,
  Amount DECIMAL(10,2),
  FOREIGN KEY (CustomerID) REFERENCES Customers(CustomerID)
    ON DELETE CASCADE
    ON UPDATE CASCADE
);

主な特徴：

ON DELETE CASCADE — 親のレコードが削除されたときに、子のレコードを自動的に削除します。
ON UPDATE CASCADE — 外部キーの値を自動的に更新します。
複雑なシナリオでは、カスタムアクションのためにトリガーを使用することが可能です。

ヒント付き問題。

カスケード削除はすべての関係にとって常に最良のプラクティスですか？

いいえ："歴史的"データやアーカイブ情報に対しては、カスケード削除は貴重な情報の損失を引き起こす可能性があります。各種類の関係のビジネス価値を理解することが重要です。

親テーブルのPRIMARY KEYに外部キーが含まれていない場合、ON UPDATE CASCADEは機能しますか？

ほとんどのDBMSでは、外部キーはカスケードをサポートするために、一意のまたはPRIMARY KEYを参照する必要があります。そうでない場合、コマンドは機能しません。

カスケードチェーンは許可されたネストレベルを超えることがありますか（再帰）、その場合どうなりますか？

はい：大規模なカスケードにより深さ制限を超えることがあり（SQL Serverの場合は32）、これによりエラーとトランザクションのロールバックが発生します。

よくある間違いやアンチパターン

弱い管理下でのカスケード削除 — 重要なデータの損失の可能性。
大量変更のログ記録の必要性を無視する。
パフォーマンスを考慮せずにトリガーを構築する（例：無限再帰を引き起こす）。

生活の例

ネガティブケース

仕入先と注文の管理システムでON DELETE CASCADEを使用し、顧客が重要な仕入先を誤って削除すると、すべての注文が自動的に削除され、納入履歴が失われました。データを回復することができなくなりました。

利点：

最小限の手作業。

欠点：

ビジネスヒストリーの損失。

ポジティブケース

ON DELETE SET NULLを使用し、ログ記録のためのトリガーを追加しました — 顧客レコードが削除されても、注文履歴は保持され（非アクティブなステータスが割り当てられる）、偶発的な大量削除は発生しませんでした。