どうも、最近コンビニ飯に飽きてきた人です
今日は「本当にあったやらかしDB設計⑤【第三正規化病】」に続いてびっくりしたことを紹介します
#見えない削除フラグ
そもそも削除フラグとは何でしょうか
レコードに専用のカラムを用意し、その値が0であれば未削除、1であれば論理削除、とする手法のことです
しかし、削除フラグは良い方法ではありません
下記でかなり詳細にわかりやすく説明されているので是非見てください
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
削除フラグは手間を増やしたりバグになる可能性を持ってはいますが、注意していれば取り扱うこともできます
見えない削除フラグはとりあえず削除フラグを凌駕する問題です
どういうことかと言うと、削除フラグを立て忘れる、ということです
###何が悪いの？？
生きているデータと死んでいるデータが混ざります
これは通常の削除フラグにも言えますが、見えない削除フラグでは死んでいるデータを死んでいるデータと判別することができなくなります
###問題
見えない削除フラグはいくつかの問題を引き起こします
- 本当は死んでいるデータなのに生きているデータのように見えます
途中で処理をキャンセルされたデータが、処理途中のデータに見えます
タイムスタンプを使って怪しいデータを炙り出すことができますが、本当に処理途中のデータなのか、途中で処理をキャンセルされたデータなのかのを削除フラグを使って見分けることはできません
- 死んでいるデータを捨てられなくなります
本来であれば削除フラグが立っているレコードは定期的に削除、または他のテーブルに移動するなどの処理が行われます
結局処理をするのであればそもそも削除フラグが存在している意味は更に薄くなりますが…
それはともかく、削除フラグが立っていないためデータベースに永遠に残り続けます
これは明らかな負債です
長く運用していると見えない削除フラグが立っているレコードの量が馬鹿にできなくなってきます
それを永遠に保存するために一体いくらかかるのでしょうか…
ゴミを保存するのにお金使いたくないですよね
###原因
なぜこんなことが起こってしまうのかは単純です
削除フラグを正しく取り扱えていません
###解決方法
######削除フラグを適切なタイミングで立てよう！
削除フラグを立てるタイミングを少なく見積もっていると見えない削除フラグを生み出します
データを削除する時だけではなく、処理が途中でキャンセルされた時にも削除フラグを立ててください
######ログをあさろう！
既存の見えない削除フラグに対応するにはアプリケーションを変更することはもちろん、今までのログをあさって死んでいるデータを見つけ出す必要があります
お金と時間がかかる作業だと思いますが、何もしないよりかは安くて済みます
#まとめ
- 削除フラグに頼るな
- 削除フラグを使うなら正しく使え
削除フラグに頼っていると、古いデータを削除するのではなく削除フラグが立っているデータを削除しようとする、というような問題も出てきます
生きているデータと死んでいるデータを分けることは、データを正しく取り扱うためには非常に重要です
データを「おまけ」ではなく「主役」として考えることで良いシステム設計ができるようになります