リレーショナル データベースでは、論理的な削除を使用するのが非常に一般的です。これらの削除をカスケードすることが本当に必要かどうかについて考えてみます。私が不思議に思う理由は、論理的な削除をカスケードしても追加情報が追加されないように思えるからです。
つまり、テーブル MainContract とテーブル ServiceContract があり、関係が 1 対多であるとします。MainContract を論理削除するとしますが、それを無視して、すべてがこの MainContract に属する 3 つの ServiceContract があるとします。
削除されていない ServiceContract の DB を照会すると、ServiceContract を所有する MainContract が削除されているかどうかを簡単に確認できます。
熟考を定式化するだけで、ここでのデザインの選択は、おそらく頻繁に削除する可能性が高いか、または歴史的な記録をたくさん閲覧する必要があるかによって決まることに気づきます.
頻繁に削除するが、それほど頻繁に履歴を確認する必要がない場合は、簡単な方法で削除することをお勧めします (論理的な削除をカスケードするのではありません)。一方、履歴レコードを頻繁に取得する必要がある場合は、複雑なクエリが少なくて済むように、カスケード削除を実装する価値があります。
ただし、リレーショナル DB では、多くの場合、行はそれ自体では意味がありません。したがって、いずれにせよ、行を意味のあるものにするためには、「ツリーの上に」結合する必要があります。たとえば、ServiceContract は、それが属する MainContract を知らなければ意味のある情報を提供しない可能性があります。
誰もこれについて何か考えがありますか？これらのアプローチのいずれかまたは両方を使用した人はいますか?