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