Re: Does Codd's view of a relational database differ from that ofDate& Darwin? [M.Gittens]

From: Mikito Harakiri <mikharakiri_nospaum_at_yahoo.com>
Date: 7 Jun 2005 15:33:49 -0700
Message-ID: <1118183629.782752.105780_at_g47g2000cwa.googlegroups.com>


Paul wrote:
> I disagree; suppose 90% of salaries are unknown. Someone does a quick
> query to get the total estimated salary bill, not realising this. They
> are going to get a shock when the real thing comes through!
>
> I would have thought that it would be safest to return an "unknown",
> flagging to the user that there are unkown salaries in the column. Then,
> having been alerted to that fact, they can proceed to use COALESCE to
> explicitly treat the NULLs as zero if they want.
>
> But I think (and this is a subjective opinion) that treating unknowns as
> zeros or empty strings should be manually defined behaviour rather than
> the default.
>
> And the "salary" column could be thought of not as a numeric column, but
> as a column that holds the answer to the question: "What is employee X's
> salary?"
>
> Now adding support for this involves a lot more complication at the
> domain level, but maybe it's worth it. I guess only experience of using
> such a system will tell.

Because we have nulls the developers and entry clerk now can afford to be lazy and type nulls even where it takes a little thought to figure out the correct value. Take the Bonus/Sales_Comission column, for example, in the Emp table. If Bonus is null I bet that this person had _no_ bonus, or Bonus = zero. Naturally, someone would want to know what the total (salary+bonus) compensation were and, oops, he has to program around this nulls mess. Received on Wed Jun 08 2005 - 00:33:49 CEST

Original text of this message