>>Modern DBMSs will achieve peak performance only with data held in RAM cache. If these servers are disk-bound then they have CPU cycles to burn, and overhead in converting 1 byte to 8 bits may be of little consequence, compared to paging out to disk. So, to get the most mileage out of the usually limited and precious RAM, using 1 bit instead of a whole byte may actually improve overall performance.
>>
>>So, I guess efficiency will never truly go out of style :-)
>
>I don't think the value is being stored in a bit. I've seen C++ headers from VS define it FALSE as 0 and TRUE as 1. Regardless of the data type, they're going occupy at least one byte, if not more, of memory.

A C++ program manipulating the data might be required to use at least a byte for the boolean. If so, that's its cross to bear :-) However, I see no reason why SQL Server should have to suffer from the same limitation.
>
>I just find it a bit strange that it's not being defined as its logical opposite. Computers do what they do because of the recursive definition of the state of a bit. It's either opened or closed, set or clear. When I was studying programming principles, defining things in terms of something that had already been defined was not only encouraged, but expected. It's simply consistent with the way the machine works.
>
>Not that defining TRUE as 1 is wrong or anything. You could define it as 42 (yes, that's a Douglas Adams reference) or anything expect zero. I just find it odd, and apparently it was just the way MS did it. No reason, or anything else.

I'm surprised, too - every language I've studied (I haven't studied BASIC :-)) uses 0 for FALSE, and a non-zero positive integer (usually 1, as you noted) for TRUE.