論理削除が奪うもの

論理削除が奪うもの JPOUGのAdvent Calendar 12/10担当です。 12月 - 忘年会シーズンです。酒で記憶を失っている際に、怒ったとか、近くにいた人にカラんだとか、脱いだとか、毛を燃やしたとか、エレベーターホールにズボンが脱ぎ捨てられていたとか、会議室で靴が発見されたとか、そういう事件が多発する月ですね。皆様いかがお過ごしでしょうか。 微塵も記憶がない状態で、やらかした内容を色々な人から聞かされるにつけ、穴を掘って蓋してセメントで埋めてもらいたくなるのは常ですが、こういう時はどんな対処を取ればいいんでしょう。 得てしてロクでもない行動を取った時の翌日における参加者の記憶力の良さと来たらFlight Recorderも真っ青です。 なんとか失敗を無かったことにしたいと立ち回りたいですが、まあ無理です。各所にヒアリングを重ねれば重ねるほど確度と精度が高まります。エビデンスま

[t-wada]

"「データは事実。事実は消えない。」という大原則を、論理削除などというアンチパターンに汚染されることなく正しい姿を取り出してあげて下さい" 『SQLアンチパターン』に論理削除の章も加えたいなぁ

[moro]

"論理削除フラグ属性って、割と一律定義されるケースが多いのでなおさらこの刷り込みに汚染されがちなんです。" ありすぎてツライ。同業者が言い出したら論理って何で削除とは何かと問い詰める運動を始めている

[iakio]

論理削除はアンチパターンだと思う。現在の状態と過去の履歴を安易に1つのリレーションに詰め込んでいる。そして外部キー制約と超絶相性が悪い

[yukung]

“それでも物理削除と論理削除を比べるとなお論理削除の方が罪深い” "論理削除有無を設定する属性が定義されている時点で、開発者は『ああ、この表のデータって削除していいんだ』という暗黙の了解に思考を縛られる"

[tgk]

三次元主義の直観と四次元主義のRDBとの激突

[masaru_b_cl]

“現実では削除なんて発想はなかなか生まれないです。だって事実は消えないのですから。なのにアプリケーションでは消せる。これは不自然なことなのです。”

[Horiuchi_H]

“論理削除などというアンチパターン”

[warufuzaketaichi]

“冒頭の忘年会失敗談はすべてが私の体験ではありません。近くで目撃はしました”

[jiskay]

論理削除なテーブルはunique制約に引っかかったりして辛い

[suginoy]

“現実では削除なんて発想はなかなか生まれないです。だって事実は消えないのですから。なのにアプリケーションでは消せる。これは不自然なことなのです。 ”

[fumikony]

なるほど

[a2ikm]

有効無効って意味で論理削除は使うけど、railsでいうacts_as_paranoid的なものを使うとその意味がコードに現れなくなるので使わなくなった。データ保全が目的ではないからちょっと違うかもしれない

[ko-ya-ma]

>本来削除されてはいけないモノに対して削除要否の検討機会をひっそりと奪う。そう、論理削除は積極的に削除を推奨するわけではなく、静かに「削除してもいいよ」と囁き続ける。だからこそ気付かない。

[yojik]

普通はユーザアカウントの有効/無効とか(論理的に削除したいけど物理削除はいけない)リソース系データでに削除フラグをつかうのかなーと思ってた。(もちろん、きちんとしたカラム名をつけるべきだけど)

[koyancya]

そうですな constraint references の形骸化とかありますな