> In my legacy CB86 application, I store up to 15 Boolean flags
> (Y/N) type fields in a small integer (16 bit) fields).

...

FWIW I do have some fields that I refer to as "bitset fields"
in my databases. These are just integer fields in which I
manipulate the bits using my own variations of BIN_AND, BIN_OR
UDFs.

For some often used bitsets I have specific UDF functions for
testing and altering each bit. This gets around the lack of
named constants in SQL. Instead of magic numbers appearing I
use a UDF to test/set/clear the bit "by name".

I use IBObjects-aware checklist components to allow the user
to interact with these bitset fields.

I do this stuff for various reasons - but not for performance
or storage space reasons. Mostly its a matter of convenience.
Each bitset has 32 bits whether I use them or not. This
allows me to expand the options in an application without
changing the database - and for some circumstances this is
very convenient.

But you do have to watch out. You cant change the order of
what the bits represent - without lots of updates to all the
rows carrying such fields and manipulating all the bits to
match.

As far as individual boolean field representation I use
smallint these days. I started trying to use a char(1) field
but found it way too confusing. Now I have all my boolean
related udfs (including the bitset stuff) return smallint
forced to 0 or 1. It all makes much more sense to my C/C++
programming mind.

--
Geoff Worboys
Telesis Computing