purazumakoiの[はてなブログ]

技術メモから最近はライフログも増えてきてます。

DB 物理削除 論理削除

いままでは、企業サイトCMSをメインで作ってきて
あまり考えることなく論理削除にしてきてた。

物理削除の最大のメリットは

  • 一つのテーブルのデータ量が軽減される

だと思う。これにより、複雑なシステムになるほど、selectのレスポンスが良くなる。

論理削除の最大のメリットは

  • データの復旧が容易

なことだろう。
ユーザが自発的に消したとしても、プログラムのバグで消したとしても容易に復旧が出来る。


しかし、これがサービスサイトになってくるとデータの量が全然違ってくるので
検索に非常に時間がかかったりする。
ましてや、削除どころか編集履歴(前のリビジョン)を残すようにもなってきている

データ登録フローに

  • 申請 → 差し戻し → 再申請 → 承認(公開)

とかの申請周りのシステムでリビジョンも残そうと思うと、
やはり

  • 公開用テーブル
  • 削除済みデータテーブル

といった用に、テーブルを分けないと、一つのテーブルデータが肥大化して、selectに時間がかかるようになる。
それを

  • DB側のチューニングや
  • INDEXを適切に貼るなど

DB側のテクニックでなんとかするという手もあるが
無理にテーブルを一つにしようとすると、ECサイトとかだと、「公開商品数カウント用テーブル」とかが入りたりして(実際は上手いやりかたをしているのかもしれないが)

いずれにしろ

  • テーブル複数体制

にして、フローを確立したほうが、無難な気がする。


技術力を伸ばすのは結構大変だし、教育がいるけど、フローなら理解させればそれほど教育コストが要らないかなと思う。


※とはいえ、DB周りはいままであまり気にする必要がなかったのでこういう考えだけど、技術的な勉強はしないとな。