⛳

【SQL】【DB設計】delete_flagについて調べたこと

2022/07/23に公開

delete_flagとつけると、「削除していいもの」と思わせてしまう。

営業: これ削除ボタン押したら管理画面からも消えるんだけど？
エンジニア: え？当たり前じゃないですか
営業: あー困る困る。削除はユーザーさんから見えなくして欲しいだけで、管理画面では見える必要があるの。
エンジニア: ...わかりました(削除じゃねーじゃん！)。

アンチパターンの解説 - 3/8 より

「あるエンティティ定義に、論理削除有無を設定する属性が定義されている時点で、開発者は『ああ、この表のデータって削除していいんだ』という暗黙の了解に思考を縛られる」

5年後のある日、新人エンジニアがサービス改修をしていた。
delete_flagをgroup byしてみると、

	SELECT delete_flag AS delete_flag FROM users GROUP BY delete_flag
		
----------
	1
	2
	0
	9
	NULL

delete_flagに2,0,NULL!?
先輩に仕様を聞いてみると

0: 未削除
1: 削除済み
2: 管理者による強制削除
9: 抹消
99: よくわからない
NULL: バグで入る

削除のコードを読んで、1が削除なのか、0が削除なのか、はたまた9が削除なのか調べる必要があります。

SELECT bug_code, date_reported, summary
FROM Bugs
WHERE is_deleted = 0

→カラムにNULLが入るとインデックスを使えないためデメリットがある
→問題解決になっていない。(結局WHERE句を多用しなければならないし)

CREATE TABLE Bugs(
	id varchar(20) NOT NULL
	status varchar(20) NOT NULL
)

例えば、「有効、中止、キャンセル、廃止予定」のような状態だ

アプリケーションは現実を何かの業務等々の観点で抽象化したものであり、それが扱うデータは事実に忠実にモデル化されたのなら残り続けているはずなのです。現実から事実を消し去ることは不可能。

T字型ER手法というのをベースにしたテーブル設計での原則

そもそもテーブルやレコードの中身がわかる適切な名前をつける
「失敗から学ぶRDBの正しい歩き方」より

テーブル名を見て中のデータを想像できないといけません。
データベース設計で絶対役に立つ命名規則