Re: So what's null then if it's not nothing?

From: mountain man <hobbit_at_southern_seaweed.com.op>
Date: Thu, 24 Nov 2005 07:35:52 GMT
Message-ID: <s3ehf.2601$ea6.1877_at_news-server.bigpond.net.au>


"FrankHamersley" <FrankHamersleyZat_at_hotmail.com> wrote in message news:EYXgf.1705$ea6.525_at_news-server.bigpond.net.au...
> mountain man wrote:

>> "paul c" <toledobythesea_at_oohay.ac> wrote in message 
>> news:CIQgf.578722$tl2.426979_at_pd7tw3no...
>>>mountain man wrote:
>>>>"paul c" <toledobythesea_at_oohay.ac> wrote in message
>>>>>Frank Hamersley wrote:
>>>>>>JOG wrote:
>>>>>>>michael_at_preece.net wrote:

> [..]
>>
>> The technical implementation of the handling of null values
>> within the different RDBMS and DBMS software vendors
>> such as Microsoft, Oracle, IBM, etc are diverse, as are
>> the various kinds of breakfast cereals.
>

> Do you know of a reference that explains these variations succinctly - I
> must admit my breadth of vendor quotient is quite low.

This may have some comparisons in some section: Are SQL Server, DB2, and Oracle really relational? http://www.handels.gu.se/epc/archive/00002948/

> Until now I had assumed most (if not all) performed the 3VL fandango in
> the same direction around the dance floor - especially the (NULL == NULL)
> is FALSE outcome.

They have a lot of common elements, but you'll find a set of divergent properties as well.

> I had (previously?) thought the angst in this issue was more driven by ppl
> being aggravated by the "apparently" non-sensical outcomes when NULL
> values appear in join elements and/or procedural code and lead to
> unexpected results (bugs).

I look at this sort of stuff as data integrity issues, and a fact of life to be resolved by the IT crew at any database site.

Pete Brown
www.mountainman.com.au Received on Thu Nov 24 2005 - 08:35:52 CET

Original text of this message