Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!unisoft!fai!sequent!lugnut
From: lugnut@sequent.UUCP (Don Bolton)
Newsgroups: comp.databases
Subject: Re: Outerjoin implementation?
Message-ID: <42868@sequent.UUCP>
Date: 24 Sep 90 21:42:00 GMT
References: <1990Sep20.161204.13014@tfic.bc.ca> <11034@sybase.sybase.com>
Reply-To: lugnut@sequent.UUCP (Don Bolton)
Distribution: comp
Organization: Sequent Computer Systems, Inc
Lines: 38

In article <11034@sybase.sybase.com> jeffl@sybase.Sybase.COM (Jeff Lichtman) writes:
>> 	select qqsv,count(*) from foo
>> 	group by qqsv
>> produces a separate line for every row in foo that has a null in qqsv...
>
>It's not supposed to.  This is one of those cases where nulls are supposed
>to act like they're equal to each other.  Does Informix SQL treat each null
>as a separate group?
>
YEP, in the above example they sure do.
then select count(*) from foo where qqsv is null produces one row with the
total of nulls.

>BTW, I agree that nulls in SQL leave a lot to be desired.  I'm not convinced,
>though, that default values are adequate in place of nulls.  There's the
>problem of having to choose a default that's guaranteed never to be represented
>by known data values.  There's the problem of accidentally using a default
>value in a calculation as if it were a true value (calculations with null
>always yield null).  

                    >There's the problem of storage space - many database
>systems don't use any space on disk for null values, which can save a lot
>in sparsely populated tables. 

This is one that gets me about Informix (aka Datachow), I may be mistaken
but I believe it pads nulls with spaces, least thats what comes out on the
selects. Also the columns are all filled to their defined size regardless
of the length of the data string. select max(length column) aint in the
vocabulary. Handy to have and use when you've inherited a used DB that had
all of the design forethought of, well the idea is there :-)

>There's the problem of naive users incorrectly
>interpreting default values as true data.  And on and on....

Like the mail thats returned addressed to Bozo Clown @ Large Feet Inc. :-)
OR TEST RECORD NOT FOR MAILING TEST RECORD DO NOT MAIL :-)

Oh *naive* users.