それは特定の質問ではなく、もっと一般的な疑問です。
1：Mの関係で複数のテーブルを削除する必要がある場合は、カスケード削除を使用してFK制約を作成するか、deleteステートメントでテーブルを結合することをお勧めします。
関連するテーブルに対して個別のdeleteステートメントがある古いプロジェクトがあり、ステートメントの一部が実行されず、データの整合性が損なわれることが数回ありました。私は2つの間で決定を下さなければならなかったので、私は少しより良い解決策が何であるかを考えていました。
ストアドプロシージャまたはトランザクションを作成するオプションもあります。
だから私は意見やアドバイスを探しています...？
カスケード削除を使用する方が安全だと思います。結合を使用する場合は、親テーブルから何かを削除するたびに結合を使用することを忘れないでください。そして、それを行うのに十分な訓練を受けていたとしても、将来あなたのソフトウェアをサポートする同僚や人々について確信を持てません。また、テーブルの関係に関するそのような知識を複数回エンコードすると、DRYの原則に違反します。
ただし、カスケード削除を使用する場合、誰も何も覚えておく必要はなく、子行は必要に応じて常に削除されます。
カスケード削除は多くの問題を引き起こすため、非常に危険です。私はその使用をお勧めしません。そもそも、何百万もの子レコードがあるレコードを削除する必要があるとします。データベースをロックして、何時間も使用できなくする可能性があります。データベースでカスケード削除を使用できるようにするdbasはほとんどありません。
次に、FKを定義している場合は、データの整合性には役立ちません。子レコードがまだ存在する場合の削除は失敗します。これは良いことです。たとえば、顧客が既存の注文を持っている場合、削除を失敗させたいと思います。カスケード削除を無意識に使用すると（私の経験では通常そうですが）、本当に削除したくないものが削除される可能性があります。
データベースに適切なRIが定義されている場合は、データの整合性が損なわれることはありません。関連するすべてのテーブルには宣言型RIが必要です。つまり、子がまだある間は親を削除できません。
また、時々一部の行のみを削除するコードがある場合、それは不十分なコーディングと不十分なテストです。これらの種類のアクションは、単一のトランザクションである必要があります。ストアドプロシージャを使用するという提案は、その問題を解決するための優れたアプローチであり、かなり標準的です。
すでに述べたように、カスケードトリガーには、誰かが削除するつもりのない行を削除する危険性があります。特にデータの問題を修正するときに、アプリケーションの外部からデータにアクセスする人がいる可能性があることを考慮してください。誰かが誤って間違った親を削除しようとして、良いRIエラーが発生した場合。彼らが誤って間違った親を削除しようとして、その親だけでなく、他の5つのテーブルの20人の子も削除された場合、それは悪いことです。
また、カスケード削除は非常に隠されています。開発者が親の削除をコーディングしている場合は、子の世話をするために削除ストアドプロシージャを使用する必要があることを知っておく必要があります。開発者にそれに対してコーディングせず、エラーを取得し、コードを修正する（または、開発者が削除をスローして実行するよりも、実際にはすべての削除を実行したくないことに気付く）ことをお勧めします。コードが公開されるまで、それが子供を殺していることに誰も気づきません。
IMO、私は開発者にアプリケーションについての知識を持たせたいと思っています。開発者がアプリケーションを知らないままにしやすくするよりも。
両方を使う！
「結合された」手動削除は、削除をより小さな作業単位に分割できるため、通常、デッドロックやその他の競合の問題を回避するのに適しています。競合がある場合は、競合の原因を見つけるのが間違いなく簡単です。
前述のように、「カスケードの削除」は参照整合性を完全に保証します。
したがって、両方を使用します-デッドロックとパフォーマンスの問題を回避するために、結合されたsqlの「子」を明示的に削除します。ただし、「CASCADE DELETE」を有効のままにして、見逃したものをすべてキャッチします。親を削除するときに子供が残っていないはずなので、削除を間違えた場合を除いて、費用はかかりません。間違いを犯した場合は、参照整合性を維持する価値があります。