はい、炎上します（タイトル的に）
まあここに書かれていることにはいろいろ言いたいこともあるが、特に個人情報にまつわる仕様としてのべき論についてはみんながブコメしているのでよいです。
で、問題は削除フラグという考え方なんですが、僕が昔炎上プロジェクトで学んだいちばん大事なことは「RDBで履歴管理をしてはならない」ということですね。ちょっと言い方が悪いがここで言う履歴というのはログとか（まあログをRDBで持つのは大概だけど）、アクセス履歴的な履歴レコードの話ではなく、データレコード自体に履歴的な項目を入れて管理してはいけない、ということで、データレコードは現状の状態を正確に持つべきだし、削除されたレコードはそのテーブルに置いてはいけない（物理削除したら消えますので当たり前ですが）。すなわち以下の三原則を適用すべき（てきとーにでっち上げたのでジョークだと思って）。
削除フラグを用いないとユニークにならないテーブル設計をすべきではない
これ、よくあるんだけど、主キーのはずの項目がDBで履歴管理をした結果として削除フラグを持っている死にレコードと、生きている単一レコードが同居するという地獄が発生することがあります。うん、確定した変更データを前の情報に戻したいとかわかる。わかるがやめろ死ぬ。
削除フラグをオフにしてはならない
一個目の話とおんなじなんだけど、結局こういう管理になるのは何故かと言うと、削除フラグをオフにすれば元に戻るじゃん的発想が悪い。死ぬ。アカウントの復活みたいなのは全部フラグオフれば戻るじゃん、というのはそういうクソ機能のために設計変更を阻害するので死ぬ。別の手段を用意すべき
そもそも削除フラグを持つべきではない
削除フラグなんてものがあるからみんな期待するんだよ。なければ解決。
削除フラグに依存するシステムは相当な技術的負債を負うことになる。大抵のことはちゃんとしたデータ設計をすれば削除フラグなんてなくても実現可能だ。ユーザーマスタに退会フラグがあるみたいなのはまだ許せなくはない。これだって混乱の元だしフラグ見忘れる事故なんてすぐ起きると思うので正しいのは別のテーブルにぶっこむかログ吐くくらいにしとけと。
こういう、アーキテクチャのお作法的なものはもちろん流儀がたくさんあるし適用されるシステムによってだいぶ事情が異なるとは思うけど、少なくとも「削除フラグ」が有効に機能することを意図して作られたシステムはおおよそ苦労している経験しかない。誰か削除フラグのハッピーな使い方知ってたら教えて欲しい。
