ネットではもしかすると、データベースに「削除フラグ」をつける設計は間違っているという声が大きいかもしれないが、それが本当に正しいかどうかはまた話は別だと思う。
もうすこし、冷静に現実を見るべきかとは思う。技術（エンジニア）の話は、技術だけで閉じていればそれで正しいのかもしれないが、ビジネスやサラリーマンでやっている話なので、ほかの要因も絡んでくるので、別の正しさもあるでしょう。
これ、DBの正規化と似ていて、正規化大好きな人たちは、とことん正規化にこだわるんですな。少し前から、ネットでもあえて非正規化することでの高速化手法とかが出回っているので、今時はそうでもないですけどね。
正規化されていないテーブルがある設計は、なぜ筋がわるいのか？とかに置き換えて考えてみてもよいかも。
有効に使える事例をしれば、また話は変わってくるんだと思うんですよ。
また、気を付けなければいけない点は、
片方（反対派？）は一般論化されているので一般論で論理を構成しやすいけど
もう片方（容認派？）は、ケースバイケースのように一般化しにくい論理でしか構成できないという違いがあります。
・blog: 削除フラグって必要？
・RDB - DELETE_FLAG を付ける前に確認したいこと。 - Qiita
・Kazuho's Weblog: 論理削除はなぜ「筋が悪い」か
・Re: 論理削除はなぜ「筋が悪い」か - Blog by Sadayuki Furuhashi
データベースに「削除フラグ」をつける設計は、まちがっているという論理は、技術者なら容易に作れる論理だと思います。ちょっとデータベースをかじった人でも、余裕で作れる論理だと思います。
考慮すべき点
RDB - DELETE_FLAG を付ける前に確認したいこと。 - Qiita「特にOracleのような高機能なDBはFlash Recovery Tableなどで～DBをまるごと戻すにしても、それくらいの事態が起こってるんだろうから、多少コストかけてもやればいい。」これ本気で言ってんのかなぁ。
2015/03/24 12:04
僕も､同じ意見です。
それぐらいの事態が起こっているからといって、コストをかけれるかどうかは別で、
なぜか、コストをかけれない場合の方が多いので、そこまでしなくても良い方法論を残しておくほうが安全だとは思う。
DBをまるごと戻すには、別環境を用意しないと怖いので、もっとコストがかかると思います。
RDB - DELETE_FLAG を付ける前に確認したいこと。 - Qiitaまず最初に、オペミスからの削除と業務フローとしての削除を分ける必要があると思っている。混ぜるな危険。
2015/03/24 09:46
業務系って、オペミスでの削除があまりありえないという風に考えてもいい場合が多いことも事実だと思います。これ、エンジニア視点ではよくわからないんだけど・・・。
業務とかにもよるけど、そもそも削除というのが少ないわけですよ。
RDB - DELETE_FLAG を付ける前に確認したいこと。 - Qiitaリストアがどんなに簡単であっても、消してないデータを見るよりは遅いわな。オペミスで1行消したからといって特定時点の20万行を環境を別途用意してリストアしてください、とか誰も依頼しないだろ。。
2015/03/24 10:37
オペミスでなくても、何かあった時に、そこまでできないっていうケースは多々あると思います。
作るのが専門のエンジニアだと、実運用での顧客対応とかが分からないので、特に気を付けた方がよいかと思います。
RDB - DELETE_FLAG を付ける前に確認したいこと。 - QiitaこれのせいでUNIQUE制約つけれなくてイライラすることはよくある
2015/03/24 13:02
これはありますね。性能ネックになりかねない場合もあるので、これは正当な反論になるとは思います。
RDB - DELETE_FLAG を付ける前に確認したいこと。 - Qiita
- [データベース]
- [設計]
- [論理削除]
100テーブル超えのシステムになるとこの辺の検討をしてるかしてないかでアプリ側の負荷が大きく変わってくる
2015/03/24 12:55
「削除フラグ」をつけても、何とかなる場合があるとは思うけどね。
履歴を残す必要があって、削除フラグで代用すべきでないという場合もあるとはおもうし、履歴用のテーブルを別に持つ必要はないという場合もあるかと思う。
削除フラグへの反論
プログラムがつくりにくい。ロジックが美しくなくなる
これはあるんだけど、極論、作り手側の都合なんで、この路線を押して賛同をえるのは、そういう思想の人だけ。削除フラグがあるだけで、変な？SQLを書かないとダメだとか、いろいろ変な感じはすることは多いとは思う。
性能ネック
これは重要な話なので、これで反論できるのなら辞めさせることはできると思う。ただ、実際にはそれほど性能ネックにならない感じの場合が多いので、無理そうな気がする
・削除フラグがつくレコード数は最大何件？
これかなり少ない
ほか思いついたら書く
「削除フラグ」をつける、明らかに変な設計もある
まあ、明らかに変な設計もあるのも事実なんで、それに関しては何とも言えないけどね。削除フラグはなんでもダメみたいな人がいるように
なんでも削除フラグをつけてしまうという人はいるわけです。
これって、予備フィールドをつくっておくとかそういう手法の延長なのかもしれません。ホスト時代とか昔のことをあまりよく知らないので分かりませんが、そういう時代のノウハウを引きづっているというのも確かにあるかもとは思います。
それだけで、切り捨てるのは辞めた方がよいと思います。
ただ、勘違いした若者が、年寄りにそうすべきだと教えられて、機械的に採用しているという事例は見たことがあるので、若者はもう少し、その意味や理由を考えるべきかなぁと思います。
削除フラグをつかう設計をするのは老害とか年配者が行うものだと思い込んでいる人もいるが、そうではない場合もある。勘違い若者エンジニアみたいな・・・。
データにも種類がある
・マスタ（台帳）的データ・トランザクションデータ
厳密にわけれない中間的なテーブルもあるわけだけど・・・。
削除フラグを持たないで、履歴テーブルを別に持てばよい
それこそ、ケースバイケースで、削除フラグがダメだという理由になってない時もあるような。参照用のテーブルと、更新用のテーブルは別にすべきみたいな路線で、結局、どこかにひずみが移動しているだけのような気がするんですね。
メリットとデメリットを比較して判断すべきというのが正しい路線であるのなら、
その比較って、一般論だけで構成できるの？という話もあるとは思う。
害が少ないものは、スルーしておくという処世術はある
あまり良くない設計だけど、それほど害がない場合はスルーしておくという処世術はあるかと思う。そんな態度が設計を悪くするんだとか思う人には無理な方法論だけど、実際、どこかで妥協して次に進まないとダメな場合が多いのも現実だと思うけどね。
だって、一人で作るわけじゃないので・・。
削除フラグは必要ないのなら、代案を！？
・SQLアンチパターン 幻の第26章「とりあえず削除フラグ」・はてなブックマーク - SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
たいていの場合、代案のほうがダメだったりする。
代案がよければ、たいていは削除フラグに固執する人たちはまずいない。
削除フラグを付けることで、逆にDBの整合性を維持しやすい場合もある。
マスター（台帳）系の削除は特に、残しておいたほうがよい。
スポンサーリンク
コメントを残す