[mailto:[EMAIL PROTECTED]]
Sent: 14 October 2002 18:34
To: Multiple recipients of list ORACLE-L
Subject: No Nulls? (was: Warehouse design: snowflake vs star schemas)
On the link below is this quote from C.J.Date:
I don't want you to think that my SQL solution to your
problem means I
Ho Ho Ho - never heard of companies with dead persons on the payroll?
peter
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: 14 October 2002 21:49
To: Multiple recipients of list ORACLE-L
Subject: Re[2]: No Nulls? (was: Warehouse design: snowflake vs
Yes - the right answer. And can be validated with a little basic
normalisation.
peter
edinburgh
Thinking about Matt's question, would it be proper to move
the column to a
EMP_TERMINATED table with an outer join on EMPNO? There
wouldnt be any
NULLs...
Rich
Rich Jesse
');
-Original Message-From:
Grabowy, Chris [mailto:[EMAIL PROTECTED]]Sent: Monday, October 14,
2002 5:11 PMTo: Multiple recipients of list
ORACLE-LSubject: RE: No Nulls? (was: Warehouse design: snowflake vs
star schem
Hmmm...but what about the index? Which is
faster?
select * from
Author: Marc Perkowitz [EMAIL PROTECTED]
Date: 10/14/2002 2:09 PM
RE: No Nulls? (was: Warehouse design: snowflake vs star schemThis is true. But
you still need to add logic to your application to suppress displaying the
termination date when it is = 01/01/4000. I can pretty well guarantee
PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: 14 October 2002 21:49
To: Multiple recipients of list ORACLE-L
Subject: Re[2]: No Nulls? (was: Warehouse design: snowflake vs star s
I'll agree with Igor. Actually my 'preferred' option would
be to use their
birth date + 80 years which
]]
Sent: 14 October 2002 21:49
To: Multiple recipients of list ORACLE-L
Subject: Re[2]: No Nulls? (was: Warehouse design: snowflake vs star s
I'll agree with Igor. Actually my 'preferred' option would
be to use their
birth date + 80 years which is the generally accepted life
expectancy
Author: "Igor Neyman" [EMAIL PROTECTED]
Date: 10/14/2002 12:14 PM
RE: No Nulls? (was: Warehouse design: snowflake vs star
schemEND_EMPLOYEMENT
date for still employed employees equals to "01/01/4000" (or any other
pre-defined date in distant future).
Igor Neyman, OCP DBA
On the link below is this quote from C.J.Date:
I don't want you to think that my SQL solution to your problem means I
advocate the use of nulls. Nulls are a disaster.
Of course, he doesn't expound upon it (probably not a need except for
dummies like me). Anyone care to comment? (On the
Subject: Re:No Nulls? (was: Warehouse design: snowflake vs star schem
Jesse,
I'll refrain from personal comments, but on CJ's quote,
he's correct. Nulls
are an oddity. They cannot be true or false (column_name = NULL or
column_name != NULL), nor can they equal anything
:No Nulls? (was: Warehouse design: snowflake vs star schemas)
On the link below is this quote from C.J.Date:
I don't want you to think that my SQL solution to your problem means I
advocate the use of nulls. Nulls are a disaster.
Of course, he doesn't expound upon it (probably not a need except
Jesse,
I'll refrain from personal comments, but on CJ's quote, he's correct. Nulls
are an oddity. They cannot be true or false (column_name = NULL or
column_name != NULL), nor can they equal anything. They are in effect a third
logical state of nothingness. You also have to code most
: No Nulls? (was: Warehouse
design:
m snowflake vs star schemas
ORACLE-L
Subject: Re:No Nulls? (was: Warehouse design: snowflake vs star schem
Jesse,
I'll refrain from personal comments, but on CJ's quote,
he's correct. Nulls
are an oddity. They cannot be true or false (column_name = NULL or
column_name != NULL), nor can they equal anything
? (was: Warehouse design: snowflake vs star schem
Jesse,
I'll refrain from personal comments, but on CJ's quote,
he's correct. Nulls
are an oddity. They cannot be true or false (column_name = NULL or
column_name != NULL), nor can they equal anything. They
are in effect a third
world.com [EMAIL PROTECTED]
Sent by: cc:
[EMAIL PROTECTED] Subject: No Nulls? (was: Warehouse
design
Title: RE: No Nulls? (was: Warehouse design: snowflake vs star schem
No application that I can reasonably think of should
use NULLS, except those pre-81
where there are obsolete columns.
Everytime somebody says this to me, I ask them:
How do you handle still employed employees
Title: RE: No Nulls? (was: Warehouse design: snowflake vs star schem
END_EMPLOYEMENT date for still employed employees equals to
"01/01/4000" (or any other pre-defined date in distant future).
Igor Neyman, OCP DBA[EMAIL PROTECTED]
- Original Message -
From
Title: RE: No Nulls? (was: Warehouse design: snowflake vs star schem
The
problem I see with NO NULLS is that artificial data must be created, where the
data is truly not known. Whether you deal with NULLs or artificial data, you
will always have to code accordingly, so it is a wash. Igor's
be retired.
Dick Goulet
Reply Separator
Author: Igor Neyman [EMAIL PROTECTED]
Date: 10/14/2002 12:14 PM
RE: No Nulls? (was: Warehouse design: snowflake vs star schemEND_EMPLOYEMENT
date for still employed employees equals to 01/01/4000 (or any other
pre
Title: RE: No Nulls? (was: Warehouse design: snowflake vs star schem
I disagree with the use of "dummy" values to
represent missing data. It reminds me of the olden days when we coded in
12/31/99 and such. Shades of COBOL HIGH-VALUES! You're introducing a
lot of dependenci
Title: RE: No Nulls? (was: Warehouse design: snowflake vs star schem
Or you'll have to explain to the HR manager why all of the
employees appear to be terminated!
they aren't terminated! at least not yet :-)
Igor Neyman, OCP DBA[EMAIL PROTECTED]
- Original Message -
From
49
PMTo: Multiple recipients of list ORACLE-LSubject: RE:
No Nulls? (was: Warehouse design: snowflake vs star schem
The
problem I see with NO NULLS is that artificial data must be created, where the
data is truly not known. Whether you deal with NULLs or artificial data, you
will always ha
Title: RE: No Nulls? (was: Warehouse design: snowflake vs star schem
Actually, you don't have to deal with "01/01/4000" date (at
least on "select"), all you have to do in order find currently employed
employees, is:
where END_EMPLOYMENT sysdate
asfor inserts, all you h
[mailto:[EMAIL PROTECTED]]
Sent: Monday, October 14, 2002 4:49PM
To: Multiple recipients of list ORACLE-L
Subject: RE: No Nulls? (was: Warehouse design: snowflake vs
star schem
Theproblem I see with NO NULLS is that artificial
data must be created, where t
Title: RE: No Nulls? (was: Warehouse design: snowflake vs star schem
This is true. But you still need to add logic
to your application to suppress displaying the termination date when it is =
"01/01/4000". Ican pretty well guarantee your users will not like
seeing a &q
Thinking about Matt's question, would it be proper to move the column to a
EMP_TERMINATED table with an outer join on EMPNO? There wouldnt be any
NULLs...
Rich
Rich Jesse System/Database Administrator
[EMAIL PROTECTED] Quad/Tech International, Sussex,
:
[EMAIL PROTECTED] Subject: No Nulls? (was:
Warehouse design:
m snowflake vs star schemas)
10/14/2002
12:33 PM
Please respond
to ORACLE-L
-LSubject: Re:
No Nulls? (was: Warehouse design: snowflake vs star
schemBoth would likely do FTS since at any given time
more than 50% of your employees will be current (have an end dateof
1/1/4000' making it very unlikely that the cbo would choosethis index.
The RBO, would, but it would
/2002 12:58 PM
Please respond to ORACLE-L
To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED]
cc:
Subject:Re: No Nulls? (was: Warehouse design: snowflake vs star
schemas)
Rich,
I piqued my own curiosity and looked at Database Programming
30 matches
Mail list logo
