Re: No Nulls? (was: Warehouse design: snowflake vs star schem

[Marc Perkowitz]

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 dependencies and non-intuitive information.  For instance, how do you ensure that these dummy values are used consistently across an application or database?   Yes, you will simply your SQL and perhaps improve performance (there are workarounds), but you will corresponding need to add special logic to reports and screens to suppress displaying these dummy values.  Or you'll have to explain to the HR manager why all of the employees appear to be terminated!   A null value means there is missing data.  It is not clear that 01/01/4000 represents missing data or incorrectly entered data.    Leave me my nulls!     Marc Perkowitz ----- Original Message ----- From: Igor Neyman To: Multiple recipients of list ORACLE-L Sent: Monday, October 14, 2002 3:14 PM Subject: 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: Adams, Matthew (GECP, MABG, 088130) To: Multiple recipients of list ORACLE-L Sent: Monday, October 14, 2002 3:39 PM Subject: 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 in an EMPLOYEE table that contains a END_EMPLOYEMENT date column? What's your take? ---- Matt Adams - GE Appliances - [EMAIL PROTECTED] Write a poem about a haircut! But lofty, noble, tragic, full of love, treachery, retribution, quiet heroism in the face of certain doom! Six lines, cleverly rhymed, and every word beginning with the letter s! -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Monday, October 14, 2002 2:29 PM To: Multiple recipients of list 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.  They are in effect a third logical state of nothingness.  You also have to code most applications with indicator variables to check for their existence.  All in all a real pain in the backside.  BUT, if you give me the possibility that nulls exist in the data I much prefer using them vs. many a third party solution of a single space.  No application that I can reasonably think of should use NULLS, except those pre-81 where there are obsolete columns. Dick Goulet ____________________Reply Separator____________________ Author: "Jesse; Rich" <[EMAIL PROTECTED]> Date:       10/14/2002 9:33 AM 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 quote, not on my dumminess...) Rich Rich Jesse                           System/Database Administrator [EMAIL PROTECTED]              Quad/Tech International, Sussex, WI USA > -----Original Message----- > From: Robson, Peter [mailto:[EMAIL PROTECTED]] > Sent: Monday, October 14, 2002 4:59 AM > To: Multiple recipients of list ORACLE-L > Subject: RE: Warehouse design: snowflake vs star schemas > > > Just for the record (and perhaps to confirm that there are > always two sides > to a story). Readers may like to see the article Chris Date > wrote to Ralph > Kemball on the subject of business rules and integrity constraints: > > http://www.dbdebunk.com/kimball1.htm -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Jesse, Rich   INET: [EMAIL PROTECTED] Fat City Network Services    -- 858-538-5051 http://www.fatcity.com San Diego, California        -- Mailing list and web hosting services --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from).  You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author:   INET: [EMAIL PROTECTED] Fat City Network Services    -- 858-538-5051 http://www.fatcity.com San Diego, California        -- Mailing list and web hosting services --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from).  You may also send the HELP command for other information (like subscribing).