RE: artificial values vs null

From: Lex de Haan <lex.de.haan_at_naturaljoin.nl>
Date: Fri, 24 Sep 2004 16:32:15 +0200
Message-ID: <JFEEIGBIDOCCDALDIPLNKECACJAA.lex.de.haan@naturaljoin.nl>

... and then the next question becomes:
why should all fact rows relate to a row in a dimension? and then the question after that becomes: are you going to build your own set of comparison operators and group functions,
making them aware of these domain values with a special meaning?

for example, the following condition is probably always TRUE these days: trunc(sysdate) < date '1900-01-01'

and I am also pretty sure that the MIN function on that FK column will return '1900-01-01' as soon as you have at least one fact row for which you don't know the actual date.

and I also think that the ORDER BY clause will treat '1900-01-01' like a normal date value...

By the way, I fully agree that you should always try to avoid null values in your tables, if that's possible, but there is nothing wrong with using null values in a relational database for the one and only meaning they are meant to have ("information missing") ...

Kind regards,
Lex.

---

visit http://www.naturaljoin.nl <http://www.naturaljoin.nl>

---

skype me <callto://lexdehaan>

-----Original Message-----
From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org]On Behalf Of STEVE OLLIG Sent: Friday, September 24, 2004 15:09
To: oracle-l_at_freelists.org
Subject: RE: artificial values vs null

exactly. all fact FKs relate to a row in a dimension.

>
> Is this approach meant to avoid nulls in the FK column in the
> fact table?
>
> Kind regards,
> Lex.
>

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



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

Received on Fri Sep 24 2004 - 09:28:09 CDT