Re: artificial values vs null

Dunno. I really am not against NULLs, just what I consider incorrect usage of said beasts. :)

You may well sign me up for "surrogate-key-philes" anonymous: there is not a database I design nowadays that doesn't include them. Try a 6 level parent-child hierarchy with natural keys... ¦Þ~~~

Cheers
Nuno Souto
nsouto_at_bizmail.com.au
----- Original Message -----
From: "STEVE OLLIG" <sollig_at_lifetouch.com>
> Nuno - as another kind member of the list points out (below), it's a
> design
> flaw. you're right in this example. where do i sign up for NULLophobes
> anonymous? ;)
>
>> -----Original Message-----
>> From: oracle-l-bounce_at_freelists.org
>> [mailto:oracle-l-bounce_at_freelists.org]On Behalf Of Nuno Souto
>> Sent: Friday, September 24, 2004 9:07 AM
>> To: oracle-l_at_freelists.org
>> Subject: Re: artificial values vs null
>>
>>
>> I'm a bit lost here as dw is not my forte.
>
>>> From: Katz.C_at_forces.gc.ca [mailto:Katz.C_at_forces.gc.ca]
>>> Sent: Friday, September 24, 2004 9:09 AM
>>> To: STEVE OLLIG; oracle-l_at_freelists.org
>>> Subject: RE: artificial values vs null
>>>
>>>
>>> We use a surrogate key (integer) for the key of the time
>>> (date) dimension in
>>> our datamart - saves space.In theory we we can distinguish
>>> between "date to
>>> be determined", "date not applicable" (see the datawarehouse toolkit -
>>> kimball 2nd ed). The key is is never null (but the date is).
> --
> http://www.freelists.org/webpage/oracle-l

--
http://www.freelists.org/webpage/oracle-l