Re: Naming conventions for special database objects

>> how do you name boolean values? <<

(Warning: my first Masters was in Math).  I don't use them at all.
SQL does not have the concept of Boolean values or flags. The search
conditions and CHECK() constraints are *predicate* logic.  We discover
the answer to a question (yes/no) by looking at *scalar* values in
*predicates*.  That means we don't set a flag for "is_foolicious" in
the data; we use a predicates that tests atomic facts for the
conditions that answer the question (if we can) -- WHERE foo > 12.45
AND lick = 'salty'.  The problem with flags is that they can be set in
a way that does not match the conditions.  Constantly updating them
with a trigger is a waste time and space. Not constantly updating them
destroys your data integrity.

Flags don't expand.  A "simple" yes/no survey question includes "Not
answered" and "Not Applicable" in the real world.  Preferences come in
degrees ("Rate Squid Ice Cream on a scale of 1 to 5 Stars").

This is why we say that a column is a *scalar* value -- it is a
measurement on a scale in a particular unit.  What do Boolean flags
measure?  They don't measure anything.

It is possible to have a scale with two values; my example is + and -
for the Rh blood factor.  That is a very specific physically
verifiable fact on a well-defined scale.  Very often,you can capture
the date of an event instead of a flag --"****p_date" versus
"is_****pped" for example.

Once you understand scales and measurement theory, you will not even
think in terms of flags and assembly language programming.