RE: artificial values vs null

... 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@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx]On Behalf Of STEVE OLLIG
Sent: Friday, September 24, 2004 15:09
To: oracle-l@xxxxxxxxxxxxx
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

Other related posts: