親と子の関係性のレコードは、親だけを論理削除しますか、両方論理削除しますか？

Question

質問

掲題通りの質問をさせてください。
親と子の関係性のレコードは、親だけを論理削除しますか、両方論理削除しますか？
皆さまのご意見をお伺いしたいです。

※かならず親ありきで子のレコードは取得されます。

私は両方論理削除していた方がデータ上きれいになるし、整合性？のとれないレコードがなくなるので良いと思っています。

条件・補足

構造は以下のようなイメージです。
必要最低限のカラムのみ表にしました。

親テーブル

id	deleted_at
1	NULL

子テーブル

id	親テーブルID	deleted_at
1	1	NULL

Comments

[maisumakun]

まず前提として、「どのような理由で」物理削除ではなく論理削除としているのでしょうか。

[Heidi]

今の私の環境ですと、最初から論理削除でしたとしか回答できない状態ですね。
少なからず論理削除されたデータは何か問題が発生したときにしか見ることはありません。

Answer 1

トランザクション制御して、両方削除します。

Answer 2

子だけを削除する場合は物理削除なのでしょうか？それとも論理削除？
質問からは物理削除のように見えます。

もし子の論理削除があるなら、親の論理削除と子の論理削除の意味合いは変わってきます。

子だけを論理削除する場合は無く、必ず親ありきで子を取得するなら、親だけ論理削除する方が、処理効率は良いでしょうね。

また、正規化の観点からも、親が論理削除されていれば、子も全て論理削除という状態は、正規化されていない事になります。
※子が１件でも論理削除されていれば、それを含む親も論理削除されていると判断できるという冗長な状況です。

Comments

[Heidi]

ご回答ありがとうございます。
子だけの削除する場合もあり、こちらも論理削除とする設計となっております。
親ありきで子を取得する場合であれば、確かに親だけ論理削除する方が処理効率は良いですよね。

Answer 3

具体的なイメージがつきませんが、外部キー制約を参考にするとよいでしょう
MySQL :: MySQL 5.6 リファレンスマニュアル :: 13.1.17.2 外部キー制約の使用

選択肢はいくつかあります

• 変更を拒否する
• 削除や変更を引き継ぐ
• 子が持つ親情報をNULLに設定する
• 子が持つ親情報を適当なデフォルト値に変更する
• なにもしない(制約にならない)

Comments

[Heidi]

ご回答ありがとうございます。
外部キー制約の観点では考えたことがなかったです。
参考にさせていただきます。