Re: Bitmask trickiness

On Fri, Jul 23, 2010 at 12:35 AM, Peter Hunsberger
<peter.hunsberger@gmail.com> wrote:
> On Wed, Jul 21, 2010 at 11:13 PM, Howard Rogers <hjr@diznix.com> wrote:
>>
>> On Thu, Jul 22, 2010 at 1:02 PM, Scott Marlowe <scott.marlowe@gmail.com> wrote:
>>
>>
>> >>
>> >> Why on Earth would I want to store this sort of stuff in a bit string?!
>> >
>> > Because you are manipulating bits and not integers?  I guess there are
>> > 10 kinds of people, those who like think in binary and those who
>> > don't.
>> >
>> >> I don't know about you, but I find looking at 21205 a darn'd site
>> >> easier than staring blankly at 101001011010101!!
>
> <snip> lots of stuff</snip>
>
>> >
>> > Note you can cast integer to bitstring, but there may be some odd
>> > behaviour for sign bits and such.  Which is again why I'd use the
>> > right type for the job, bit string.  But it's your project.
>> >
>>
>> Quoting...
>>
>> > Because you are manipulating bits and not integers?  I guess there are
>> > 10 kinds of people, those who like think in binary and those who
>> > don't.
>>
>> Er, no. 21205 is not an integer. It's an encoded bit of magic.
>>
>
> In that case your database design is fundamentally broken.  A database
> should have content fields that map to the needs of the application.
> As you describe your application requirements, that is a bit string
> and not an integer.  Use bit strings and your application logic is
> transparent, obvious and easy to maintain.  Use integers and you have
> to resort to "magic".  As you say, it's your choice, but you came here
> looking for advice and the advice you were given is very good....
>
> --
> Peter Hunsberger

Hi Peter:

It wasn't, as the original poster pointed out, 'advice' that was given
so much as personal preference. Had someone said, 'ah, but you see
storing your 15 meanings in decimal uses up 5 bytes, whereas a
bitstring only requires 15 bits, and over 10,000,000 records, the
saving of 3 bytes per record adds up...', then that would be technical
advice I could listen to, assess and make a call on.

But simply saying "your design is broken... wooooo!" might well scare
the children, but doesn't really do anything for me, because I know
for a certainty that it's not broken at all.

It comes down to this: I can do Boyce-Codd normal form in my sleep
(...and falling asleep happens quite frequent when doing it, strangely
enough), and have been doing so since 1987. I'm certainly not perfect,
but I reckon I can tell from a mile away when one of my designs is
"broken", as you put it -and this one isn't. I haven't even begun to
describe a scintilla of a percentage point of the design decisions
this thing has to deal with, nor the fact that it's been running quite
happily in this manner for a good couple of years... so you'll just
have to take it from me that there's a room-full of users who can look
at code '4097' and know precisely what it means and would be mortified
if I suddenly started displaying exactly the same meanings in what, to
them, would look like utter gibberish.

Unless you, or someone else, can come up with some hard, *technical*
facts as to why working with bitstring encodings of meaning is so much
better than working in decimal, we're sticking with the decimal
representation. I'll buy "you're forever doing implicit casts which
are poor performers" or "implicit casts might break in a future
release" or "it's costing you three bytes per record" ...or anything
else in that vein. But matters of transparency and ease of maintenance
are entirely subjective things (about which I sought no advice at all,
incidentally), and what works for you on those scores doesn't work for
me.

Regards
HJR