Datenbankstrukturen mit einer großen Anzahl von Bitfeldern

Question

Ich habe eine Klasse von Daten mit einer sehr großen Anzahl von binären Eigenschaften - 151 (!) Um genau zu sein - und ich bin besorgt, wie man diese Daten strukturell modelliert. Trotz der internen Effizienz, Bitfelder als Bytes zu speichern, kribbeln meine programmierenden Spidey-Sinne beim Erstellen einer Tabelle mit 151 Bitfeldern (zusätzlich zu anderen Eigenschaften).

Es wird nicht viele Zeilen geben - vielleicht 1000 und einmal in die Produktion geschickt wird sich nicht sehr oft ändern.

Ich habe darüber nachgedacht, meine Daten in disjunkte Unterklassen zu kategorisieren und separate Tabellen zu erstellen, aber die Aufteilung der Eigenschaften auf diese Weise ist undurchführbar und würde, wenn möglich, sicherlich nicht effektiv mit den Datenunterklassen abbilden. Das andere Problem ist, ich möchte alle Daten zusammenhalten und Feld- und/oder Reihendoppelung vermeiden. Ich habe auch überlegt, ein benutzerdefiniertes Binärformat zu verwenden, aber dies ist nicht praktikabel, da das Schlüsselfeld in meinen Daten als Fremdschlüssel in anderen Tabellen verwendet wird.

Bei Abfragen werden die WHERE-Klauseln stark verwendet, um relevante Daten zu extrahieren. Ich habe überlegt, mehrere longs oder int-Felder zu verwenden, aber ich habe dies als nicht ausführbar abgelehnt, da ich keine bitweisen und-Operatoren oder Funktionen in SQL kenne und wie oben erwähnt, ist die Klassifizierung der Eigenschaften problematisch, ganz zu schweigen von anderen wichtigen Software-Engineering-Probleme (mit dieser Methode).

Ich werde PostgreSQL verwenden.

Also meine Frage hier ist, mache ich nur eine Tabelle mit einer großen Anzahl von Feldern oder gibt es andere Methoden kompatibel mit dem relationalen Modell?

Answer 1

Das größte Problem, das ich sehe, ist die offensichtliche Tatsache, dass die Mächtigkeit des Einfeld-Indizes ist, gelinde gesagt, gering. Vielleicht können Sie die Daten ein wenig genauer beschreiben und wir können andere Designs diskutieren? Sind diese beispielsweise voneinander unabhängig?

Mit nur 1000 Zeilen könnte es einfacher sein, dies anderswo als die Datenbank zu speichern (obwohl ich mir vorstellen, gibt es viele Join-Möglichkeiten?) Nicht aus Gründen der Abfrage Effizienz, aber es sieht nicht wirklich wie Datenbankdaten.

Answer 2

Warum konnten Sie keine bitweisen Operatoren verwenden?

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

aus: http://www.postgresql.org/docs/7.4/static/functions-math.html

würde ich denken, dass Sie sie vielleicht Gruppe in kleinere Gruppen könnten, aber anders als zu tun, dass ich einen anderen Weg nicht kennen.

Answer 3

PostgreSQL supports bits and bit strings natively.

Answer 4

Modellieren Sie die für Ihre Problemdomäne am besten geeigneten Daten. Sie haben hier nicht viele Daten. Wenn Sie im schlimmsten Fall annehmen, dass jede Zeile 200 Byte belegt, sehen Sie weniger als 200 KB an Daten. Es ist eine triviale Menge, selbst wenn Ihre spezielle Datenbank keine booleschen Eigenschaften auf effiziente Weise implementiert.

Auf der anderen Seite, mit 150 booleschen Eigenschaften klingt etwas verdächtig, vielleicht kann Ihr Datenmodell weiter normalisiert werden?