Interesting article. I tend to agree with Joe Celko on this, BUT, the bitmask manipulation is something that a good programmer should know in the languages he/she is using.
For example, I used something similar to a bitmask to evaluate a set of hierarchial rules. I could have three factors upon which my decision is based.. (this is a simplified version of what I did in a healthcare application - it allowed for many rule factors to be evaluated in different orders with new factors being added on the fly)
2. Type of procedure
3. Intended recipient of the letter (ie referring doctor, internal notes, the patient, etc)
You can have a table storing columns such as
TemplateToUse - refers to the template table. could be NULL
SendingMethod - indicates how the letter should be sent. could be NULL
etc, etc... Other properties stored here
I set up a loop to go from 7 down through to 0 - bitmask values 111 through 000. For each loop iteration I can use the bitmask to determine whether or not I include that factor in the check for a rule match. I'm not explaining this very well - apologies (was up late!)
If I was to attempt to match for Doctor 7, ProcType 2 and RecipientType 1 to get the desired Template, sending method, etc and I had the following rules recorded
Doctor ProcType RecipientType TTU SM
null null null fallback post
7 null 1 temp1 email
7 2 null temp2 null
null null 1 null post
It depends on which rule factor has most significance (doctor, procType or recipientType) as to what eventual TTU and SM (plus others) I get. Using the bitmask to AND with my doctor=7, procType=2 and recipientType=1 factors I can check all possible rule combinations, in the correct order of checking them (from most specific to least specific) for rule values in the table. I can stop when I have all non-null values for TTU, SM, etc. My first rule in the table above (with nulls for the rule factors) ensures that I get, if nothing else was found, at least a fallback template and sending via the postal system.
Anyhow, I typically steer clear of storing "encoded" values in columns in the DB for many reasons, but a big one is that an end user attempting to write a report in Crystal Reports with very minimal knowledge of SQL and Crystal functions, etc would not be able to decode the field - bitmask, IP as integer or otherwise. Also, if you need to capture an extra bit, I'd hate to visit various reports to ensure their decoding routine can cope with the extra bit(s). If the workaround suggested is a database view that does the bitmask decoding then you might as well just store the values as discrete bits in the table anyway.
It was a good article - I'm looking forward to the next one. I like the ones that provoke good (not cranky) discussions Cheers!