私が関与しているプロジェクトの主任開発者は、カスケードに依存して関連する行を削除するのは悪い習慣だと言います。
これがどのように悪いのかわかりませんが、そうである場合/理由についてのあなたの考えを知りたいです.
私が関与しているプロジェクトの主任開発者は、カスケードに依存して関連する行を削除するのは悪い習慣だと言います。
これがどのように悪いのかわかりませんが、そうである場合/理由についてのあなたの考えを知りたいです.
行periodを削除することはめったにないと言って、これを前置きします。通常、保持したいほとんどのデータ。ユーザーに表示されないように、削除済みとしてマークするだけです (つまり、ユーザーには削除されたように見えます)。もちろん、それはデータに依存し、一部のもの (ショッピング カートの内容など) については、ユーザーがカートを空にしたときに実際にレコードを削除しても問題ありません。
ここでの問題は、実際には削除したくないレコードを意図せずに削除する可能性があることだけだと思います。ただし、参照整合性はこれを防ぐ必要があります。したがって、明示的であること以外に、これに対する理由は本当にわかりません。
あなたは最小の驚きの原則に従っていると思います。
カスケード削除によって予期しないデータ損失が発生することはありません。削除で関連するレコードを削除する必要があり、それらのレコードがなくなることをユーザーが知る必要がある場合は、カスケード削除を使用しないでください。代わりに、ユーザーは関連するレコードを明示的に削除するか、通知を受け取る必要があります。
一方、テーブルが本質的に一時的な別のテーブルに関連している場合、または親エンティティがなくなると必要になることのないレコードを含む場合は、カスケード削除が問題ない可能性があります。
とはいえ、カスケード削除に頼るのではなく、関連するレコードをコードで削除することによって、意図を明示的に述べる方が好きです。実際、カスケード削除を実際に使用して関連レコードを暗黙的に削除したことはありません。また、cletus で説明されているように、ソフト削除をよく使用します。
カスケード削除を使用することはありません。なんで?間違えやすいからです。クライアント アプリケーションに明示的に削除を要求する (そして、FK 参照レコードの削除など、削除の条件を満たしている) ことを要求する方がはるかに安全です。
実際、レコードを削除済みとしてマークするか、アーカイブ/履歴テーブルに移動することで、削除自体を回避できます。
レコードを削除済みとしてマークする場合は、削除済みとしてマークされたデータの相対的な割合に依存します。これは、SELECT
s が ' ' でフィルタリングする必要がisDeleted = false
あるためです。レコードは削除済みとしてマークされます。
次の 2 つのシナリオのうち、どちらを優先しますか。
開発者があなたのところに来て、「ねえ、この削除は機能しません」と言います。2 人ともそれを調べたところ、彼が誤ってテーブルの内容全体を削除しようとしていたことがわかりました。あなたは両方とも笑い、あなたがしていたことに戻ります。
開発者があなたのところに来て、「バックアップはありますか?」と恥ずかしそうに尋ねます。
カスケード UPDATES や DELETES を使用しない大きな理由がもう 1 つあります。これらはシリアル化可能なロックを保持しています。シリアライズ可能なロックを保持すると、パフォーマンスが低下する可能性があります。
カスケード削除を避けるもう 1 つの大きな理由は、パフォーマンスです。メイン テーブルから 10,000 レコードを削除する必要があるまでは、これは良い考えのように思えます。その結果、子テーブルには数百万のレコードが含まれます。この削除のサイズを考えると、すべてのテーブルが数時間、場合によっては数日間完全にロックダウンされる可能性があります。なぜあなたはこれを危険にさらすのですか?1 つのレコードを削除するための追加の削除ステートメントを記述する時間を 10 分短縮できるようにするためですか?
さらに、子レコードを持つレコードを削除しようとしたときに発生するエラーは、多くの場合良いことです。必要なデータがあり、削除すると失われるため、このレコードを削除したくないことを示しています。カスケード削除は子レコードを削除するだけで、たとえば過去に注文した顧客を削除した場合、注文に関する情報が失われます。この種のことは、財務記録を完全に台無しにする可能性があります。
ON DELETE CASCADE を使用すると、ほとんどの商用 ETL ツールが機能するバイナリログ レプリケーションを使用して、データ ウェアハウスでデータのコピーを維持することが難しくなります。各テーブルからの明示的な削除により、完全なログ レコードが維持され、データ チームにとってはるかに簡単になります :)