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でトリガーが使えなくて断念。
これも複雑さが増すほどメリット無いかなって気もする。
ひょっとして物理削除最強・・・・？(; ﾟдﾟ)
