論理削除はなぜ「筋が悪い」か

「論理削除が云々について - mike-neckのブログ」を読んで。 データベース設計において、「テーブルの書き換えをするな、immutableなマスタと更新ログによって全てを構成しろ」というこの記事の主張はモデリング論として全く正しい。 だが、残念なことに、ディスクやメモリが貴重な資源だった時代の技術であるRDBは、そのようなモデリングに基づいて設計されたデータベースには必ずしも適していない。 第一の問題は、RDBに対してなされる様々な「更新」（トランザクション）は不定形（どのテーブルをどのように修正するかはアプリケーション依存）だという点。不定形な「更新」を時系列にそってRDBに記録していくのは、設計と並走性の点において困難あるいは煩雑なコーディングが必要になる（というか、そのような「イベント」による「変化」はREDOログに書き、その更新された「状態」をテーブルに反映していくというのが

[iakio]

履歴が必要なら履歴テーブルを別途用意すべきところをカラムの追加で済ませた結果が削除フラグ

[n314]

具体例がないと分かり辛いな…。「現在の状態」と「更新ログ」じゃーダメなのかな。

[te2u]

実環境では、運用コストがかかる方が「筋が悪い」のだけど。

[yosuke_furukawa]

Oracleのテーブルとマテリアライズドビューが同じようなこと言ってたの思い出した

[skyriser]

削除警察

[oktnzm]

店主「deleteしてしまったんですか！？」

[watermaze]

では僕はC言語でポインタを使わないことを推奨したい、とかは20年遅れか。新しいプログラミング言語ほどの気軽さで新らしい概念のDBが出てこないのが問題な気がする

[stealthinu]

この件の一連のまとめ。このまとめを出発点として案件ごとに妥協していくみたいな設計が現実的なんだろうな。

[k-holy]

immutableなマスタと更新ログとその射影として表現される現在の状態のビュー。要件として過去の状態のうち何が必要なのか明確にすべきで、それが分からないまま妥協策で削除フラグが採用されるケースが多いんだろうけど

[oakbow]

論理削除とCRUDのUとDをなくす話の結論、総まとめ。要点が分かりやすく的確に整理されて分かりやすい。 論理削除は割りと積極的に使う方だけど、この視点で立ち止まって考える必要確かにある。

[labocho]

"現在の状態を持つ" か "更新ログで歴史を全部持つ" かなのに、前者に過去の状態を持たせようとするため。

[ono_matope]

納得感が高い

[rteeeeee]

「「削除フラグ」というのは、「現在の状態」を表現するテーブルに過去の状態の一部を表現する機能を場当たり的に足したもの（なので筋が悪い）」

[masa8aurum]

納得した。 >「削除フラグ」というのは、「現在の状態」を表現するテーブルに過去の状態の一部を表現する機能を場当たり的に足したもの（なので筋が悪い）

[pyaoo]

Kazuho's Weblog: 論理削除はなぜ「筋が悪い」か

[pmc12]

Kazuho\'s Weblog: 論理削除はなぜ「筋が悪い」か

[o_hiroyuki]

設計

[tyru]

immutableなマスタ、更新ログ、その2つから合成可能な「現在の状態を表現するビュー」ってaufsみたいだなー。確かに操作履歴とデータの整合性を取ろうと思ったらこういう設計になるか…／あーこれ大福帳型データベースだ

[oppara]

論理削除はなぜ「筋が悪い」か B!

[minoru0707]

物理削除派ですお

[bobbyjam99]

Kazuho's Weblog: 論理削除はなぜ「筋が悪い」か :

[b-wind]

“ただ、immutableなマスタ、更新ログと「現時点のビュー」の３テーブルを準備・運用するというのはそれなりにコストがかかる”

[rryu]

この理論を実装したDBMSが既に普及していてもよさそうなものだが、何か知られざる問題でもあるのだろうか。

[htnmiki]

賢い人が作って賢い人が使うシステムはこれで良さそう。残念だが賢い人は少ないので庶民は削除フラグ使っといたほうが幸せになれそう。

[nakag0711]

RDBが時間軸を意識しないモデルなのは構造的欠陥の感あり。だれかスマートな拡張モデルで新しいRDB作ってくれないかなあ

[muddydixon]

ケースバイケース

[yamadar]

なるほど

[gowithyou]

いい問題提起。あるべき姿と運用するうえでの利便性との妥協が論理削除ということだと思う。テーブルの正規化と同じじゃないかな。このDBが解決してくれるのではないかと期待。http://hozumi.github.io/2012/03/datomic-ja.html

[you21979]

更新ログだけで管理するとかってblockchainだよなぁ。。。

[nilab]

Kazuho's Weblog: 論理削除はなぜ「筋が悪い」か

[h-yano]

誤操作で削除されたデータを簡単に戻せないと、実際、運用に耐えられないのでは。。。

[sds-page]

エンドユーザーの誤操作でデータが消えないような設計なら良いのかな？具体例も無いしちょっと現実的じゃない提案

[key_amb]

データモデル的にきれいな設計にすることで、性能問題が起こらないかと、かえって構成が複雑にならないかは考えた方がいいと思ふ。 / Kazuho's Weblog: 論理削除はなぜ「筋が悪い」か /

[progrhyme]

データモデル的にきれいな設計にすることで、性能問題が起こらないかと、かえって構成が複雑にならないかは考えた方がいいと思ふ。 / Kazuho's Weblog: 論理削除はなぜ「筋が悪い」か /

[twainy]

ありかなしかで言うとあり。色々考えたけどまったく問題ないという結論になった。よほどの人気サービスじゃなければたぶん大丈夫

[deep_one]

バックアップや障害対応としてはありだけど、実稼働する奴ではそもそも動作速度的にきついのではないかな。NoSQL系はそんな感じで動いている気もするけど、そのかわり「唯一無二の回答」を期待されない。

[Kiske]

Oracleのマテリアライズドビューのことを思い出した