多数のビットフィールドを持つデータベース構造

Question

非常に多数のバイナリプロパティ - 151（！）が厳密な - 私はこのデータを構造的にモデル化する方法に関心があります。ビットフィールドをバイトとして保存するという内部的な効率にもかかわらず、私のプログラミングでは、151ビットフィールド（他のプロパティに加えて）を持つテーブルが作成されています。

大量の行はありません。おそらく1000になり、一度生産に送られると頻繁に変更されません。

自分のデータを分離したサブクラスに分類し、別々のテーブルを作成することを考えましたが、この方法でプロパティを分割することは実用的ではなく、可能な場合でもデータサブクラスとは効果的に対応しません。もう1つの問題は、すべてのデータをまとめてフィールドや行の重複を避けたいということです。私もいくつかのカスタムバイナリ形式を使用することを検討しましたが、これは私のデータのキーフィールドが他のテーブルの外部キーとして使用されるため、実行できません。

クエリは、関連するデータを抽出するためにWHERE句を頻繁に使用します。私は複数のlongまたはintフィールドを使用することを検討しましたが、SQLでビット単位の演算子や関数がないことを知っているので、これを実行不可能なものとして拒否しました。上記のように、プロパティの分類は、ソフトウェア工学の問題（この方法で）

私はPostgreSQLを使用します。

ここで私の質問は、膨大な数のフィールドを持つテーブルを作成するか、リレーショナルモデルと互換性のある他のメソッドがありますか？

Answer 1

私が見る最大の問題は、単一フィールドインデックスのカーディナリティが低い、控えめに言っても、であることは明らか事実です。データをもう少し詳しく記述でき、他のデザインについて話し合うことができますか？これらはすべて互いに独立していますか？

1000行だけでは、データベース以外の場所に格納するほうが簡単かもしれません（結合機会がたくさんあると思いますが）。クエリの効率上の理由ではなく、実際にはデータベースデータのようには見えません。

Answer 2

なぜビットワイズ演算子を使用できませんでしたか？

& bitwise AND 91 & 15 11 
| bitwise OR 32 | 3 35 
# bitwise XOR 17 # 5 20 
~ bitwise NOT ~1 -2 

から：http://www.postgresql.org/docs/7.4/static/functions-math.html

私はあなたが多分小さなグループにグループ化して、私は別の方法を知っていないことをやっ以外にできると思うだろう。

Answer 3

PostgreSQL supports bits and bit strings natively.

Answer 4

問題のドメインに最も適したデータをモデル化します。最悪の場合のシナリオでは、各行が200バイトを占めていると想定して、200KB以下のデータしか見ていないとします。特定のデータベースが効率的な方法でブール値のプロパティを実装していなくても、ほんのわずかです。

一方、ブール値のプロパティを150にすると、疑わしいと思われます。データモデルをさらに正規化することは可能でしょうか？