Auch wir arbeiten tatsächlich in unserer
DB und im
RAM mit eigenen Datentypen, in welchen wir per Propertys auf die SubFelder bitweise zugreifen und per Operatoren sogar rechnen
Unser Ansatz manueller Ansatz:
- wir arbeiten nich mit Delphi "BitFeldern", sondern im DelphiRecord mit Array(s) of UINT64,UINT32,UINT16,BYTE
- wir platzieren zuerst alle Subfelder mit einer ganzen "8er" Bitgröße an INT64..BYTE grenzen (und "optimieren" hier schon das erste Mal)
- wir prüfen, ob es 2 Subfelder kleiner ganzer BYTE..INT64 gibt
- wir fangen für 1..7Bit SubFelder so an: wir platzieren dann immer 2 der längsten unrunden Subfelder so, das eines linksbündig und eines rechtsbündig an einer BYTE..INT64 Grenze ist und dazwischen der nun "zusammenhängende Platz" ist und füllen diesen mit den kleinen SubFeldern auf
- dann für 9..15Bit usw... verteilen und/oder optimieren
Das ist deterministisch und damit bekommt man schon sehr kleine Records bei "guter" Feldverteilung.
-aber manuell optimieren wir das teils noch etwas besser
-manuell können wir drauf achten, das es sogar sortierbar wird, wel z.B. die "wichtigen" Bits der Schlüsselinformationen "vorne MSB->LSB" stehen
-negative Werte speichern wir positiv mit einem extra Zusatz "SignBit", weil das beim (Aus)maskieren mit SHL,SHR,AND,OR einfacher zu setzen/prüfen ist, als fehlende negative EinserBits nach Schieben über TypGrenzen wier aufzufüllen
-sehr große oder sehr kleine Zahlen speichern wir mit einem FaktorIndex z.B. 4Bit für 10^(-8..0..7), "Stichwort: eigener FixCommaDatentyp"
-im Idealfall brauchen wir beim LeseZugriff pro SubFeld nur 1x AND und eventuell einmal SHL bzw SHR... das geht wirklich sehr schnell und ist Mutithread auf AMD CPUs sogar viel schneller wie deren lahmer DOUBLE-FPU Flaschenhals
Auch wenn es sich in der Anfrage eventuell nur um "typenlose" Bitfelder handelt, glaube ich das man dies per SoftwareAlgo so angehen könnte.
(Ich mache es weiter manuell, denn ohne die Datenkodierung bei mehr als 100Mio Datensätzen hätten wir wirklich auch heute noch ein Platzproblem sowohl im
RAM als auch im Storage. Ausserdem ist es zusätzlich ein guter Schutz gegen Fremddatenzugriff, denn Scriptkiddys können mit so bitweise verwurschtelten Daten nix anfangen, und wenn eventuell noch ein Paritätsbit spendiert wird, ist das sogar ein Sicherheitsargument)