仕事をしているときに、ふと論理削除フラグをどう表現すべきか？で悩んでいた時に
以下の記事を見つけた。
論理削除フラグは状況によってアンチパターンになるらしい。
それはなぜか？
開発時に参照するプログラム側で考慮が必要
つまり、「論理削除フラグを必ず入れる」など必要なわけです。
また、これをどのようなときに0、1にするなど考慮も必要です。
まぁ必要な処理が多くなってしまうわけですね。
外部参照先で論理削除フラグについて考慮する必要がある
テーブル結合だったりで論理削除フラグを付け忘れることが結構あります。
または、脳死で論理削除フラグ=0をつけると、逆に仕様を満たせなくなってしまうとか…。
無駄に考えるべき点が多くなってしまいますね。
マスタが汚れる
人によると思いますが、良く分からないカラムがマスタにあるのは可読性を損なうとは思います。
というより、マスタの全体を見たときにデータの状態が分かりにくくなるのが嫌ですね。
論理削除フラグという名前が抽象的すぎてどういう状態か分かりにくい
多くはDELETED_FLAGとかdel_flgとかそんな名前が設定される印象ですが
このカラム名から「なぜそのデータはフラグが立っているのか？？」というのが分からないと思います。
つまりは実態を見て判断することは難しく、コメントやプログラムや設計書など外部の資料を見ないと
分からないことが問題です。
値を見る必要がある
これは、論理削除というものを根本から覆しますが
中が0，1などBooleanのような形で入っていない場合、何も信用できません。
2や3などがあった場合は、混沌を極めます( ;∀;)
脳死でつける可能性がある
割とあります(´・ω・)
ルールで設定しなければならないが、処理として1になる処理はいれていない。など。
脳死で論理削除フラグを付け、後からこのフラグは切り替わっているのか？手動でだれか変更したのか？
フラグ処理入れてしまっていいのか？など、後々無駄な調査が増えるきっかけになるでしょう。
ならば、論理削除フラグの利点とはなにか？
以下の1点に尽きます。おそらくこれがなければここまで普及していないでしょう。
・スイッチイング（切り替え）が容易。
他のところで言えば、以下のポイントもありますが、そんなに重要な所ではないでしょう。
たくさんのデータをDELETEやUPDATEするのは、バッチなど即起動しなきゃならない処理ではないでしょうし。
・DELETEよりUPDATEの方が早い
なぜ切り替えが容易なのが重要なのか？
データを物理削除した場合、復旧に手間がかかるためです。
イレギュラーパターンや想定外の現象が起きた場合…などで復旧に時間がかかると、相手の仕事に影響してしまう。
まぁ悪いのは開発者ではないですが、予期せぬ事態に備えていないわけにもいかない。
論理削除があれば、最悪このデータだけでも戻して！！（原因よくわかんないけど！！！）とかの時に
とりあえずスイッチングする、ということが可能というのも大きいのではないかと思います。
※仕様通りではあるけど後でデータの中身は見たい…などの要求や、確認したいからデータくださいとかが
あったりするので、物理削除ではなく論理削除にせざるを得ない…というパターンもある。
個人的な論理削除フラグの是非
個人的に言うと、「論理削除フラグがない世界」を味わったことが無いので
どれだけ処理をシンプルにできるのかあまり想像がつかないでいます。
ただ、論理削除フラグ自体は脳死で着けるべきものではないと思います。
特に、その実装の時点でフラグを変更することがないのであれば、つけるべきではないと思います。
また、あまりよくないかもしれませんが論理削除フラグというあいまいな名前にするくらいなら
ちゃんとした状態のカラム・テーブルを用意してそこに相応の値を設定するべきじゃないかと思います。
結論としては、脳死で付けるなという話ですね。