読者です 読者をやめる 読者になる 読者になる

セカイノカタチ

世界のカタチを探求するブログ。関数型言語に興味があり、HaskellやScalaを勉強中。最近はカメラの話題も多め

マーブルワーズ

CURDは死んだのか。と、論理削除

Re: 論理削除はなぜ「筋が悪い」か - Blog by Sadayuki Furuhashi

論理削除の話が盛り上がっているので考えて見ようと思った。

まず、自分の立場では、論理削除賛成で追記型のimmutable DBは懐疑的。

ドキュメントDBとかオブジェクトDBとかはよくわからないので、RDBMSを前提として考える。

論理削除の良い所

運用中にヤバイデータをサクッと消せる

Deleteフラグを立てれば良いので。

運用していると、ゴミデータが入ったとか、バグで変なデータが出来たとか良くあるので、とりあえず消して置けるのはありがたい。

正直物理削除でも良い気もしているけど、貧乏症なのか。

ちなみにカラム名は、deleted_atとdeletedの2つをセットにする派。

論理削除の悪いところ

データを取る時にdeleted = 0 とかを必ず付けないといけない。

または、Viewで管理。

immutableのためにテーブルを分ける

上記の記事を読んだけど、複雑すぎるので運用無理な気がする。

Keep it simple stupid.

追記型

例えば、全てのテーブルにシーケンシャルなカラムを(キーとは別に)持ち、同じキーならば、シーケンシャルが新しい方を正とする。

この形のテーブル設計を採用したプロジェクトをやったことがあるが、運用が論理削除より圧倒的にめんどくさかった。

それをカバーするためにViewを作ったりFunctionを作ったりすると沼なのはimmutableと同様。

PostgreSQLの内部構造が追記型なので、レイヤーを1つ上げて車輪の再発明をしてるだけな気がする。

Vacuumとか、PostgreSQLが何年も掛けて解決してきた問題と再び対峙するのかしら?

てか、PostgreSQL採用してVacuumしないでrawデータ見ればいいだけじゃ。。。

リスト型

これを考えている時に、前のバージョンを参照するポインタを持つのはどうだろうか。リスト構造だ。

create table person {
    id serial,
    name varchar,
    old_id int8
}

こんな形のテーブルを定義して、消したいときは、old_idに古いidを入れた新しい行を追加。

誰からも参照されていないデータが正。

正のデータかどうかの判断が死ぬな。インデックス貼ればいいんだけど。

単に関数型っぽくってカッコイイかなと思いました。(ぉ

まとめ

結局、論理削除って妥協の産物でしか無いんだけど、他と比べて我慢できる程度のデメリットしか無いので、それでいっかな。ってポジションだと思った。

他に良い案がアレば採用するけど、「これで勝つる!」って案が、大概メチャ複雑な管理を要するとか。。。

DBは、頭悪い人も触るので、冗長でもなるべくシンプルに済ませたいというのが願い。

ヒストリーテーブル

番外として、トリガーを使って_historiesというテーブルに書き出す処理をつけてたことがあった。

これを採用しているプロジェクトも多い気がする。

ヒストリーテーブルとトリガーの定義を自動化してくれるなら便利で良かった。

PostgreSQLを使ってた頃は、よくやってたけどMySQLでトリガーが使えなくて断念。

これも複雑さが増すほどメリット無いかなって気もする。

ひょっとして物理削除最強・・・・?(; ゚д゚)