Question

Could someone point us to information on (or opine on) BITMAP usages to store 100’s of indicator-like (on/off) attributes of a data object.

For example, if the “California” record in the STATE table had 120 indicator-like attributes and these attributes uniquely identify California, would it be wise to store these indicators in a VARCHAR(2) field (assuming a 64-bit system)?

We use the 120 attributes to resolve to California’s surrogate key. Our Db is SQL Server. We are also discussing adding 120 one character or one bit fields or a single VARCHAR(120) field.

Many thanks for all help!

Answer 1

VARCHAR(2) stores 2 characters, not ‘128 bits on 64-bit platforms’ as you seem to expect. Besides, the internal representation is such as to honor the guarantee that the on-disk format is portable across architectures. Ie. 64-bit system represents the VARCHAR(2) the same way as an x86 system.

If you want to store bitmap, that would be binary data, then use BINARY type. You can represent 120 attributes in a BINARY(16) type. Such a storage is very dense and space efficient, but is very difficult to search and index. While SQL Server supports bitwise operators, searching such a bitmap field for example to retrieve all records that have bit 7, bit 12 off and bit 18 on can only be done by an end-to-end, size-of-data, table scan.

Also, instead of using a BINARY(16) field to store 120 single bit attributes, consider declaring 120 BIT columns in the table. They would require 2 bits for storage (one bit for data, 1 bit for NULLability), but your code will be much cleaner and readable as it actually manipulate named columns as opposed to cryptic bitwise operations. Sargability of this solution is same as the BINARY(16) one (ie. no seeks, only table scans).

You should also read about sparse columns and filtered indexes, both concepts are very likely to apply to your design.