When space is an issue, something that doesn’t happen very often, we can optimize storage by taking advantage of bits instead of using an entire byte to store a value. In fact, depending on the number of values needed for a specific tuple, you can break up a byte into multiple values.
If you had 8 bool values they could all be stored in a single byte, given that you don’t allow null. If you had a property having three values, you could store them by using 2 bits, and assigning the binary values to 1, 2, 3, all numbers available in two bits using binary settings. Obviously, you can continue to extend on to as many bits as you have need for options.
Why would you even care about something like this? Disk is cheap. Ram is cheap. Bit masking and bit mapping require a lot of careful coding and can be error prone, difficult to test, visualize, etc. I worked on an RF Tag project a few years back where we stored an entire manufacturing bill of materials for a motor, on an RF tag with a max memory value of 8k. The entire bill of materials was essentially stored in a blob that was completely meaningless. You required a data map to the blob to allow you to determine where your desired data was located…what offset from the beginning, for how many bits. This worked well because we didn’t have a lot of character data, so we were able to break everything down to the smallest identifier possible. The machines all worked automatically with the codes.
The most fun part of the whole project was writing an ORM. Our objects were one big blob, that needed to be mapped to many different tables. I remember writing the data access code, and the mapping routines to write and read from different locations in the blob. Using Dot Net and stored procedures was quite interesting, and I found that TSQL supports a surprising amount of operators for bit manipulation.
One thing I remember most from this project is that if we had chosen to store the data as a blob, it would be a very difficult database to use for anything other than reading and writing to tags. We did actually store the blob data. However, we also stored real lookup tables and engine instance data, allowing reports and applications to be written that were readily understandable by humans without a hex editor, and a decoder key.
Once again, the consumer does not drive the database design.
Cheers,
Ben