From: | Mike Mascari <mascarm(at)mascari(dot)com> |
---|---|
To: | Jon Earle <je_pgsql(at)kronos(dot)honk(dot)org> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Nulls get converted to 0 problem |
Date: | 2003-06-06 17:34:16 |
Message-ID: | 3EE0D098.5010300@mascari.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Jon Earle wrote:
> On Fri, 6 Jun 2003, Mattias Kregert wrote:
>
>
>>1. Imagine a table with dates and weather conditions. How would you
>> differ between "zero degrees" and "no data entered yet"? You would
>> have to add a column (degrees_valid boolean). Having the NULL value
>> makes things much easier.
>
> <click!>
>
> Thank you Mattias, the differences (and similarities) are now clear.
Some people think NULLs have no business in databases:
http://www.hughdarwen.freeola.com/TheThirdManifesto.web/Missing-info-without-nulls.pdf
And that they cause unforeseen logical problems:
http://www.firstsql.com/iexist2.htm
There also isn't any notion of typed NULLs. At least the C++ example
has a zero-initialized pointer to a type.
The meaning is overloaded. Does NULL mean:
"I don't know" or
"I can't know" or
"Not applicable" <- This usually implies a non-normalized database
They also require a full implementation of RI (MATCH PARTIAL) if the
attributes are involved in PK/FK relationships.
They cause problems in representations when moving data into and out
of the database between non-SQL systems, as evidenced by this thread.
I'm not sure of the current state, but in older versions of
PostgreSQL, NULLs weren't indexable.
I'd avoid them. But that's just my humble opinion...
Mike Mascari
mascarm(at)mascari(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Bruno Wolff III | 2003-06-06 17:35:12 | Estimate of when CVS will be available again? |
Previous Message | Rory Campbell-Lange | 2003-06-06 16:41:02 | Re: Return Record |