Re: The BOOLEAN data type

On 8 Apr 2003 16:11:22 -0700, 71062.1056_at_compuserve.com (--CELKO--) wrote:

>>> Let's say you have a table of product orders and you need to know
>which one's have been shipped and which one's haven't. That's a
>boolean value that can't be computed from other data. <<
>
>Wrong:
>
> CREATE TABLE Orders
> (order_nbr INTEGER NOT NULL PRIMARY KEY,
> ..
> ship_date DATE, -- null means not yet shipped
> ..);
>
>And please don't tell that you would not record the shipping date,
>shipping charges, shipping method, etc. in the database.

Hm, please do tell why is a good thing that standard forces you to put in to your physical model fields that are not needed (for some business rules storing such property might even be _forbidden_ !)?

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.

However the principle is not ok.. you can _not_ know (in 100% cases) weather I _need_ or _am able_ (without additional costs) to store shipping charges, shipping method, etc.! You can't even know if I am allowed to store this or similar surrogate constructs.

Standard should not force you to do so...

Also, we _are_ talking about standard and physical implementation of the database where redundancy is acceptable AFAIK.

If my model only cares about Female property for an entity, and if this property has domain (True, False) in my model's semantics and I do not need to generalize into obvious then shouldn't I be allowed to model as such?
Sure, I might want to capture more meaning, but what if I can't?

Simple example:
I store a result of test and a date/time of this test for a particular individual. This test tells me if this individual is female or not. This is all I need to know. Period.

And sure - one can always store boolean values as expression: (some property = some value), but isn't this complexity overhead in general?

All the best

( GoranG79 AT hotmail.com ) Received on Wed Apr 09 2003 - 10:56:25 CEST