返信の受付は終了いたしました。
-
-
- 読み込み中...
基本的には、必要なテーブルのみで採用すべきです。
そもそもテーブル設計時に、論理削除にするかどうか、慎重に検討します。
ビジネス要件に、削除したデータも、後から見れるようにしたい、ということは当たり前にありますから、必要があれば、そうします。
ただ、全部のテーブル、というのは疑問です。
仮にフレームワークを使っていたとしても、です。
また、論理削除しても、3ヶ月などの一定期間がたったものから、物理削除のバッチを当てることもあります。そういう場合は、物理削除の前に、削除データのみ吸い上げ、S3などに永久保存するようなバッチをかましてからになります。
つまり、UI面のことはユーザー側に対してのアラートなので、それはそれで重要ですが、本質的には、何かあった時のために、古い過去であっても遡りたい、ということが論理削除時の要件目的であることが多いため、現実的なバランスを見ながら、実装工数を考えます。
もしフレームワークの力を使わずにそういうことをやっているのであれば、バグの温床になる可能性があるので、そういうのはフレームワークに任せたいところです。 -
-
-
- 読み込み中...
全部ではいらんなー。リレーションで整合性が取れなくなる場合、例えばユーザーを消すと購入履歴とかおかしくなる時などは必須かも。まあリレーション取らないデータの方が珍しいが -
論理削除を全部のテーブルで実装しようとしている、自称エンジニアのディレクターがいます。(本当にエンジニアだったのかも怪しいだけど)
そんな事やりだすと、システムの規模がデカくなればなるほど、不都合生じそうだなと思っているのですが、そんなことはないですか？
もちろん、論理削除を楽に実装できるような機能はフレームワークを使っていれば、あるんでしょうけど、複雑なクエリを発行したい場合は、なんの障害もなくできるのかと言うと本当にそうなのかなと....
重要なテーブル以外は、そんな事するより、削除ボタンを押したときに確認アラート出すなりで、ui面を見直すだけで解決できるよなって思ってしまいます。