Re: Outer Joins are Evil?

From: <tim_at_sagelogix.com>
Date: Tue, 31 Aug 2004 09:32:32 -0600 (MDT)
Message-ID: <3921981.1093966352647.JavaMail.oracle@ocs.sagelogix.com>

Steve,

Reason #1 is a clear case of altering reality to fit a theory. Every parent must have at least one child at all times? Doesn't happen in the real world and it doesn't happen in data either. Anyone who makes that assertion doesn't know how to design or implement a user interface and they certainly don't understand data warehousing, for heaven's sake. Tell them to buy Kimball's "DW Toolkit" and learn real DW design principles instead of making stuff up based on their past inexperience.

Reasons #2 is bunk. Silly ideas waste time and should be avoided at all costs, leading to sillier distortions like #3.

I suggest that you demand that they either substantiate their basic assertions (#1 and #2) or retract them, like professionals.

While we shed most of the loonies who signed up during the internet bubble, clearly there are still some hanging in there. Give the branch a shake and see if they drop away...

Hope this helps. Best of luck!

-Tim

Forwarded message ------------------------ I'm currently working on a datawarehouse project (~5 Tb) where the decision has been made to avoid performing outer joins.

The reasons given for this seem to be -

Simplifies user navigation of the structures - i.e. avoids outer joins.
Outer joins are slow and should be avoided at all costs.
If an FK is missing it is populated with a default value which will relate to an actual row in the target table, hence no rows will ever be dropped - again, supposedly this is to simply SQL and avoid outer joins.

What they actually do is populate each table in the structure with three default rows with an SK of 0, 1 & 2. Any FK's which are missing, not applicable or invalid will point to one of these rows.

Now....my question is....what is so inherently evil about outer joins that we go to this extreme to avoid them?

AND...has anyone else seen something like this deployed in other places?

Thanks,

Steve.
----------------------- End forwarded message ------------------------

Please see the official ORACLE-L FAQ: http://www.orafaq.com

To unsubscribe send email to: oracle-l-request_at_freelists.org put 'unsubscribe' in the subject line.
--

Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html

Received on Tue Aug 31 2004 - 10:30:40 CDT