I recently
had an opportunity to review a Microsoft Access query created against one of
our production databases. The query seemed to run forever and took up huge
amounts (4GB) of TEMPFILE space. Our development team eventually solved the
problem – an inexperienced developer had missed a critical join between one of
the six tables in the query. Moreover, since Access translates all its joins into
ANSI syntax, it took us some time to decode the SQL that caused the problem.
If you’ve
been working with SQL for some time, I’m willing to bet that the ANSI joins may
look a bit confusing and convoluted, especially if you’ve always used the "traditional"
join predicates (i.e. WHERE table1.column = table2.column). I have been writing
SQL queries since 1985 starting with TERADATA databases, back when the concept
of a terabyte of information was still intimidating. However, I must admit that
the ANSI syntax, once understood, has some advantages over the traditional
syntax.
Here is a
quick summary of how the ANSI syntax can be applied to SQL queries in Oracle
9iR2. I have provided side-by-side examples showing how the traditional vs. ANSI
syntax can be used to obtain the same result. Please note that I have utilized
the HR schema in the EXAMPLE tablespace that is provided with Oracle 9iR2 for
these examples. See the section at the end of this
document for a listing of these tables’ metadata.
NATURAL Joins. A natural join, as
its name implies, can be invoked when two or more tables share exactly the
same columns needed for a successful equijoin. For example, these queries will
return all Region and Country information for all countries whose name that
contains the string "united":
Example: NATURAL Join |
|
Traditional |
ANSI |
SELECT |
|
Note that
even though the table names are prefixed in both examples, REGION_ID cannot use
the prefix; Oracle chooses the appropriate column in the naturally-joined table
from which to gather data. If you get an ORA-25155: column used in NATURAL
join cannot have qualifier error message, check over the columns named in
the query – you may have inadvertently broken this rule.