Re: The BOOLEAN data type

From: GoranG <no_at_spam.net>
Date: Thu, 10 Apr 2003 09:22:03 +0100
Message-ID: <vtc99vgc3ovis3eo6vrtcmbffrpknupbf4_at_4ax.com>


On 9 Apr 2003 09:29:15 -0700, 71062.1056_at_compuserve.com (--CELKO--) wrote:

>>> I do agree that storing a ship_date (shipping date) makes data more
>meaningful and is a good thing in 91,7%, or so, cases. <<
>
>Accounting will not work without it! This example is a 100%
>requirement.
... of a good design (logical) of an accounting system. But accounting does not represent 100% of all possible business models, does it?

As a side note for accounting: You must agree that somewhere you will have to stop (one might say that accounting requires delivery date as well, and some other information).
Are you simply arguing that you don't ever need to stop at boolean value (as opposed to some supported type)? Or that it is bad to stop at such value (as in gather more data, not less)?

Certain accounting business model might have a following rule for IsShipped (boolean) property:
- Shipping is confirmed by authority A, where authority A has it's own rules, procedures and does not want to share any data with us except confirmation. Item is considered shipped if authority A confirms it, unless an in-house officer establishes that authority B also needs to confirm, unless the shipped item falls within certain category list which is reviewed every second quarter of a financial year.

So at the end I decide (by comparing costs) to model IsShipped property as boolean and keep all that hype which will change with the next month's law out of my model. At the same time I am consciously avoiding using an absence of a natural property ship_date since effective business rule for determining if shipment occurred certainly does not correspond to it and such artificial functional dependency could only mislead my programmers and/or incur data loss (in this example!).

This is reality. <g>

>>> However the principle is not ok ... If my model only cares about
>Female property for an entity, and if this property has domain (True,
>False) in my model's semantics ... <<
>This is a bad data model; clearly "female" is a value of an attribute;
>the domain is "gender".
At what level? Logical - yes. Physical - must I really model it as such if my business really does not care about it? (context of my models semantics determine domains, not a general consensus on 'true' meaning of things).

Furthermore we are discussing ability to do something proscribed by standard, not general guidelines for good design.

>>> And sure - one can always store boolean values as expression: (some
>property = some value), but isn't this complexity overhead in general?
><<
>
>That is not complexity; that is reality <g>! A Boolean is too general
>to carry much meaning.

Any type is inappropriate to carry meaning out of its own domain. <g>

Boolean's only difference is that its domain is so small that it can easily be included in same state transition coding scheme or other types by exploiting special values.

( GoranG79 AT hotmail.com ) Received on Thu Apr 10 2003 - 10:22:03 CEST

Original text of this message