DBのレコード上で何らかの属性・ステータスを表現するためにビットマップを使わない方が良い
true か false かで表現できる属性・ステータスの集合をビットマップで扱いたくなることがあるかもしれない
Columnに 11001010 のように持つスタイル
例えば
1ビット目は男性か女性か
2ビット目はプレミアム会員かそうでないか
などなど
それは悪手であることが多い
悪手である理由
メンテナンス性が悪い
「ビット位置」が意味を持つことになるので、一目で意味を捉えるのが難しい
ちゃんと明に意味のある値として表現されていたほうが良い
途中のビットを廃止すると歯抜けになる
廃止したビットを別の用途に転用することは基本的にできない
検索性が悪い
ちゃんと意味のある値として検索できたほうが良い
そもそもindexが有効に効かないのでは
2値で判断できないものが来た時に困る
上の例に書いたが、そもそも「男性」「女性」の2値で扱おうとするのは不適当
2ビット使えば良いという意見もあるかもしれないが、そうであればそもそもビットマップを使う価値が損なわれている
もし使いたい2ビットの間に他のビットが挟まっていた場合更にメンテが困難に……
64個以上のフラグがあったらどうするの
詰む
off-topic: 64個もフラグを付けるな！！！！！！！！！！！！
ビット列型を使うという方法はありそう
(一応) ビットマップを利用することに対する最低限の擁護
容量が少なくなるの (i.e., 空間効率) はよさそう
ではどうするのか
pgであれば普通にattributeを表現する値 (あるいはID) を text[] なりにしてGINインデックス張れば良さそう
こうすればビット列型を使うまでもなさそう (つまりビットマップを使う必要はなさそう)
そもそもstatusの組み合わせは正規化すれば良いのでビットマップで管理する必要はない
こういう使い方は良さそう
最初から属性の種別・数が完全に定まっており、増減が無い場合
上の一休.comの事例 (時間軸) なんかはこのケース
あるいはネットワークプロトコルなんかはこのタイプ
だが、このページで論じているのはDBレコード上での属性の取り扱いなので……