検索に関しては、値ごとに個別の列を使用する方が柔軟です。
異なる行に異なるブール値のコレクションがある場合、個別のキー/値テーブルはより柔軟になります。
そして、
- ブール値のリストは多かれ少なかれ静的です
- すべての行にこれらすべてのブール値があります
- パフォーマンスが重要な検索は、値のいずれかがfalseである行を見つけることです
次に、「1001010010」などのテキスト文字列を使用すると、それらを保存するのに適した方法です。このように検索できます
WHERE flags <> '11111111'
必要な行を見つけるために。
フラグごとに1ビットのBINARY列を使用できます。ただし、テキストを使用すると、テーブルをカジュアルなクエリや眼球検査に使用しやすくなります。 CHARの代わりにBINARYを使用することによるスペースの節約は、何百万もの行の格納を開始するまで重要ではありません。
編集 言わなければならないことです。ブール属性の配列を使用してこのようなものを作成するたびに、後でそれがどれほど柔軟性がないことが判明したかに失望しました。たとえば、電球のカタログだったとします。ミレニアムの変わり目に、ブールフラグは次のようなものだった可能性があります
screw base
halogen
mercury vapor
low voltage
その後、状況が変わり、
のようなブールフラグがさらに必要になります。LED
CFL
dimmable
Energy Star
など。突然、私のデータ型は、保持する必要があるものを保持するのに十分な大きさではなくなりました。 「ブール値のリストは多かれ少なかれ静的です」と書いたとき、アプリケーションの存続期間中に電球の特性のようなものが変化することを合理的に期待しないことを意味しました。
したがって、属性の別のテーブルが可能性があります より良い解決策になります。次の列があります：
item_id fk to item table -- pk
attribute_id attribute identifier -- pk
attribute_value
これは最終的には柔軟性があります。新しいフラグを追加するだけです。アプリケーションの存続期間中いつでも、既存のアイテムまたは新しいアイテムにそれらを追加できます。また、すべてのアイテムに同じフラグのコレクションが必要なわけではありません。 「どのアイテムに誤った属性があるのか」と書くことができます。このようなクエリ：
SELECT DISTINCT item_id FROM attribute_table WHERE attribute_value = 0
ただし、「属性が不足しているアイテム」というクエリは記述が非常に難しいため、注意が必要です。