MySQLで論理削除と正しく付き合う方法
- 24. 削除 フラグ︖
というかそもそも論理 削除 とか 削除 フラグなんていうか
ら話が掴みにくくなる
スーパー非表⽰フラグとか表⽰ステータスとかにすればいいんじゃ
ね︖
-
そうすれば、それはレコードの 属性 の⼀つなので、リレーショナル
モデル的に納得がいく
運営のみ閲覧可能フラグとかユーザー非表⽰フラグとかでもいい
ステータスならENUM(ʻNOT̲DELETEDʼ, ʻDELETED̲BY̲USERʼ,
ʻDELETED̲BECAUSE̲DMCAʼ, ʻDELETED̲BECAUSE̲PORNʼ, ..)とか︖
ただし”display̲status <> ʻNOT̲DELETEDʼ“とかやると死ねる。
とはいえそんなクエリー流すの管理画⾯だけであるべきなので、テーブルスキャンく
らいは覚悟しろという気でいる。
-
23/33
- 29. MySQLが5.5 <del>以降</del> より前
それ以前は インサートバッファ (INSERTにしかセカンダ
リーインデックスの非同期反映が有効でない)
DELETEはクラスターインデックスと全てのセカンダリーインデック
スを同期で反映させるのに対し
-
super̲hidden̲flagのUPDATEはクラスターインデックスはまず触ら
ないし、super̲hidden̲flagを含むセカンダリーインデックスだけ反
映させればいい
-
UPDATEにせよDELETEにせよ、MySQL 5.5とそれ以降にすることで
チェンジバッファの恩恵を受けられる
-
ということは別に前提ではないかも
28/33
- 34. Questions and/or Suggestions?
Q. インデックスの先頭にカーディナリティーの⼩さい
super̲hidden̲flagを置くのは悪⼿じゃね︖
A. ちゃんと正しい位置に置いてくれるならどこでもいいんだけど、「先頭」
って⾔っておかないとだいたいひどいことになる
Q. DELETEトリガーでアーカイブテーブルに追い出すののデメ
リットはなんかある︖
A. トリガーはトラブルシュート⾯倒。ADD COLUMNしたらトリガーが腐っ
て全部のDELETEが転けるとか。
33/33