Yule

「なぜ日本の業務システムは論理削除だらけなのか」という動画、コメント欄が120件を超えて設計思想のぶつかり合いになっているのでまとめます。 いいねが一番多かったのは、消せない業界からの証言でした。 「自治体の住民記録や戸籍、税などのシステムは、統計や過去の履歴に遡っての調査、監査などがあるから、論理削除が基本なのだ。販売管理や在庫管理みたいなシステムを扱ってたところから転職したときは面食らったけど、餅は餅屋、特性に応じての設計が大事だと思った次第なのだ」 次に多かったのが、消される側の感覚。 「ユーザー、特に非エンジニアの人からすれば、退会（削除）したつもりのサービスから自分の個人情報が流出したとなったら『は？』ってなりそうだよなぁ」 「情報流出が頻発してる昨今だと、個人情報の削除を求めたのに個人情報が漏れた、って一段上のやばい事態になる気がする」 設計者にとってのフラグ1本が、ユーザーにとっては「消したはずのもの」です。 現場で見た実装の話では、これが強烈でした。 「今まで見た中でいちばんびっくりしたのは、削除フラグすら存在しない論理削除かなあ。論理削除実行時にidの数値符号を反転させて画面から消す」 フラグ方式そのものへの不満も根強いです。 「論理にするならゴミ箱用の履歴テーブルに入れれば良い派。フラグ管理って嫌いなんだよなぁ。このフラグ一つでテーブルの性能も格段に落ちるし」 「論理削除や履歴が同じテーブルにあると、最新データを取得することに対してのルールが必要になるが、漏れが多く、必ず問題になる。それに反して、本来想定している誤削除の対応は言うほどない」 「論理削除で3年後にDBアップグレードでいらない予算を溶かすのを何回も見ているなぁ」 一方で、「とりあえず論理削除」を擁護する冷静な意見もありました。 「『とりあえず論理削除』は安全の意図もあるけど、それ以上にコスパの都合もある。問題になるときって大体運用もハッキリ見えてない。そのタイミングで、本題では無い削除の挙動の話を詰めるより、とりあえず論理削除で進める方が早い」 「データベースの寿命が長過ぎて、大昔に作ったものと今言われてるベストプラクティスがズレてることがよくある」 落としどころとして多かったのは、両方使う運用です。 「ISMSの関係で両方使う。例えば、会員が退会したら論理削除。1ヶ月経過して何もなければ論理削除したものを物理削除」 そして、論理削除が増える本当の理由。 「マネージャー『もし物理削除したことで何か起きたら、お前責任取れるんだろうな！』この手のやり取りで、どれほどのバグやトラブルが起きているだろうか…」 最後に、一番短くて一番刺さったやつ。 「ソースコードを論理削除してる所はデータも論理削除している」