DELETE_FLAG を付ける前に確認したいこと。 - Qiita

DELETE_FLAG という思考停止フラグ DELETE_FLAG という boolean の列が DB 設計でよく話題になります。 論理削除という言葉で上手に論理武装し、スキを見せるとすぐに入れたがる人がおり、 一方でそれにつよく反対する人もいます。 自分の経験としては、広義の論理削除はありえると思いますが、実現方法が DELETE_FLAG だとなった時、それはあまり考えてないでなんとなくパターンとして盛り込んでる場合が多いと感じます。 ただし、設計に唯一の答えは無いので、もしかしたらそれが妥当な設計である場合があるかもしれません。 今回は「DELETE フラグがなぜダメなのか？」などという話をするつもりも、アンチパターンだと断言するつもりもありません。 問題は、仕様をきちんと把握すると、「最適な設計は DELETE_FLAG ではない」という場合が有って、その場合は、その最適な設計

[n314]

まず最初に、オペミスからの削除と業務フローとしての削除を分ける必要があると思っている。混ぜるな危険。

[kitaj]

「特にOracleのような高機能なDBはFlash Recovery Tableなどで～DBをまるごと戻すにしても、それくらいの事態が起こってるんだろうから、多少コストかけてもやればいい。」これ本気で言ってんのかなぁ。

[kachine]

自社システムならともかく、物理削除は運用に耐えないと思う。オペミスにしろバグにしろ、いつ誰が(何の機能が)消したのか速やかに調査するのに更新日時と更新ユーザ(機能)IDと論理削除フラグの3点セットは大変有用。

[t-wada]

質問と回答のスタイル、とてもいい。アンチパターン形式に編集すれば『SQL アンチパターン』第26章「とりあえず削除フラグ」にできるのではないかと思えてくる。

[honeybe]

はるか昔「この DELETE_FLAG 列はどういう目的で必要なのですか？」と聞いた時に「コーディング規約で決まっているから」との回答を得た経験がある。究極の思考停止パターンだったので僕も考えるのをやめた。

[Jxck]

typo を指摘いただいたので修正しました。

[bbbtttbbb]

「物理で殴る」というのはややこしいこと言う客を殴ることではなかった

[k-holy]

それは解約や停止じゃなくて本当に削除なのか。一意性制約や参照整合性制約は何より重要。最近は公開フラグは使っても削除フラグは使わないなぁ。オペミス云々はデータ設計じゃなくアプリ設計でカバーするものでは

[megane1972]

「普通に使ってたら消えた」「なくなったら困るデータだから戻してほしい」を頻発する顧客がいたので、論理削除は削除時刻と削除ユーザを持たせることにしている。

[moro]

丁寧な記事で素晴らしい。

[moegg]

“これは放っておいたら、状態が発見されるたびに FLAG 列が追加されていた可能性があります。” 独立した属性の掛け合わせをすべて「ステータス」とすると常に設計書を照らさなくてはならないし仕様変更が難しそう。

[kappaseijin]

“状態が発見されるたびに FLAG 列が追加されていた可能性があります。”

[okoppe8]

コメント欄まで読むと、オペミスの可能性と影響度を考えて付けろという結論になる。アンチパターンと決めつけるのは運用への想像力が足りないかも。

[shifumin]

「「論理削除した行が復活する事がありますか？」まさかと思うかもしれないが、「ある」と答えが返ることがあります。それは削除じゃなく、状態です」

[axnsword]

論理削除 [データベース] 設計 ENUMの使い道

[ymm1x]

削除フラグ 論理削除

[a_bicky]

良い内容

[matobaa]

from Pocket September 05, 2016 at 06:30AM via IFTTT

[tettekete37564]

むやみに論理削除自体をアンチパターンとするのはいただけない。それも思考停止の一つ。

[ANNotunzdY]

Oracleさんパーティションテーブルすげー、と思ったら、MySQLにも5.1で入ったのかな？

[takahiroki]

データベース設計: 論理削除フラグを付与したくなったら

[ono_matope]

読み返してた。「論理削除フラグはダメ」じゃなくて、論理削除フラグより適したモデリングが見落とされがちだからちゃんと考慮しろ、という話だった

[bootJP]

読んでる RDB - DELETE_FLAG を付ける前に確認したいこと。 by @Jxck_ on @Qiita

[invent]

合わせて読みたい

[Pinon3s]

なるほどなあ

[sora_h]

コメント欄が香ばしい

[Dai_Kamijo]

RDB - DELETE_FLAG を付ける前に確認したいこと。 by @Jxck_ on @Qiita — 上條　大 (@Dai_Kamijo) July 16, 2015 from Twitter https://twitter.com/Dai_Kamijo July 16, 2015 at 08:30PM via IFTTT

[you21979]

論理削除便利な言葉

[seneca]

DELETE_FLAG を付ける前に確認したいこと。

[iww]

削除とは状態である という話

[ysync]

全体の規模や削除の頻度にもよるけど、運用含め他所（人）に投げる可能性があるなら削除フラグは無難じゃないかね。

[sentas]

うんうん。

[jacoyutorius]

一年前にこの記事読んでおけばよかった

[igrep]

"データが消えるということは結構レアな事だということをふまえると、論理であれ物理であれ、「削除」だと思っているその操作は、そのデータに対して行うべきこととして本当に正しいのか..."

[s-tomo]

「間違って削除ボタンを押してしまいました」というサポート依頼が結構あって、削除ステータスから別ステータスに書き換えるんだけど、元ステータスが分からないのでステータスとは分割したいと思わなくもなかった。

[tolkine9999h]

確かに、いろんなパターンあるんだけど、実際設計してるとき、メイン機能の設計に忙しくて、削除深堀するのめんどくさいんだよな。

[yajamon]

アクティブ用テーブルとアーカイブ用テーブル同時に挿入させたらいいのかしら。問題はデータをどうやって常時同期しようか……。

[gologo13]

いい記事。ステータスの一つとして削除状態を設けることはよくやる。アプリケーションエンジニアがDBエンジニアと別れてる場合はdeleteして後から復旧というのはしづらいかも

[yukung]

フラグにする前にちゃんと考えたのかって話なのにフラグはダメとか問題を避けるには必要とかって読んでる人がコメント欄や後からブコメにちらほら居て、それが本文で指摘されてることでは？

[rryu]

いわゆる下書き状態のデータの論理削除はゴミになるだけなので本当に削除したくなる。