Re: Table join expertise needed badly

"Mark D Powell" <Mark.Powell_at_eds.com> wrote in message news:1145207268.577047.52960_at_v46g2000cwv.googlegroups.com...
: Mark, the OP said that all the other tables can be related back to one
: table which makes this table, A, the logical point where many
: developers would start. However, table A may not be the best starting
: point because of the lack of filtering conditions. By looking at the
: other table entry points (know column values) it may be possible to
: identify a join of two or more tables that provide an entry point into
: the main table that filters out a high percentage of the rows.
:
: By figuring out a solution path manually this can then be compared to
: the plan the CBO produces. A comparison of the two and some analysis
: of the differences can then provide an idea of if the DBA/developer
: recongizes facts the optimzer missed or if the optimzer recognized
: possibilities that DBA/developer missed. This then serves as input to
: another attempt at determining an acceptable, perhaps even optimal,
: plan. If the ending plan paths are different between the CBO and
: developer the the two plans can be tested against one another.
:
: HTH -- Mark D Powell --
:

don't see the benefit of this one (may be a good idea, i just don't see it) ... i'd still go with the correct FK/PK joins, assuming that all tables are actually required

i might see the value in joining FK to FK (siblings) or FK to partial FK (sibling dependents), if that would eliminate usage of some of the tables -- but a good understanding of the basic relationships and why the tables are included in the query is a prereq.

++ mcs Received on Sun Apr 16 2006 - 14:17:50 CDT