Re: All hail Neo!

Frank Hamersley wrote:
> Marshall Spight wrote:
> >
> > The idea of null as something that taints everything it
> > touches doesn't seem useful or practical to me.
>
> I fully understand the sentiment however in cases like this I prefer
> arrangements that retain flexibility for the (awake) programmer and
> provide a form of simple clarity.

I agree, however I think what I described better meets these criteria than what you described! As far as flexibility goes, you can always put a CASE statement around the value if you need to.

> i.e. if there is one null the avg() is null.

I can't ever imagine a situation where this would be useful or desirable. Anyone?

Let's say I had a customer database with 1000 customers in it, and I have the age of 999 of them, and one null. Let's say I hire an analyst because I want to study some things about my customer database. Maybe I want to do some TV advertising, so I want to know some things about the demographics of my customers. I ask the analyst, what is the average age of my customer base, and what does each decile look like? The analyst comes back later, and says, the average age of our customer base is unknown. For each decile, there are 100 people, and the average of each decile is unknown, and the range of ages in each decile is unknown. I'm going to fire that analyst and get a good one.

> This simplistic approach means any stray nulls creeping into a dataset
> where none are expected will not go undetected if inadequately
> constrained queries are framed.

I don't see this as an issue. The schema controls whether nulls are allowed or not; if they are not allowed, they won't be there, and if they are allowed, they are pretty much certain to be there.

And again, if for some strange reason you want to query for that, you can.

Marshall Received on Wed Apr 26 2006 - 19:04:11 CEST