Oracle Training Oracle Support Development Oracle Apps

 E-mail Us
 Oracle Articles
New Oracle Articles

 Oracle Training
 Oracle Tips

 Oracle Forum
 Class Catalog

 Remote DBA
 Oracle Tuning
 Emergency 911
 RAC Support
 Apps Support
 Oracle Support

 SQL Tuning

 Oracle UNIX
 Oracle Linux
 Remote s
 Remote plans
 Application Server

 Oracle Forms
 Oracle Portal
 App Upgrades
 SQL Server
 Oracle Concepts
 Software Support

 Remote S


 Consulting Staff
 Consulting Prices
 Help Wanted!


 Oracle Posters
 Oracle Books

 Oracle Scripts

Don Burleson Blog 







Oracle Business Intelligence, OLAP and BI training and consulting tips . . .

Click here for more
Oracle News Headlines


Mark Rittman

What Are ANSI Joins, And Why Should I Use Them?

If you've ever had to port a Microsoft SQL Server or Access database over to Oracle, you've probably come across the different way joins are put together for these databases. For example, you might come across a query looking like this;

SELECT pub_name, titles
FROM publishers
INNER JOIN titles ON publishers.pub_id = titles.pub_id

At first you might think that this is some new dialect of SQL that Microsoft have introduced for their databases; in fact, what's actually being used here is the ANSI SQL/92 syntax for joins, which SQL Server and Access have always used as their 'default' join syntax. Historically, Oracle supported the SQL/86 standard and included their own proprietary syntax to handle areas such as outer joins.

Starting with Oracle 9i however, Oracle have now included support for many ANSI SQL/99 features including ANSI compliant joins, and there are several advantages in using this new syntax, one of which is the separation of the join condition from the WHERE clause. For example, in this example given by Damir Bersinic, the first example uses our traditional way of creating joins, whilst the second uses the new ANSI syntax.

SELECT c.CourseName, s.StartDate,  i.FirstName
|| ' '  ||i.LastName as Instructor, l.City
FROM ScheduledClasses s, Instructors i, Courses c, Locations l
WHERE s.InstructorID = i.InstructorID
AND s.CourseNumber = c.CourseNumber
AND s.LocationId = l.LocationID
AND l.Country = ‘USA'

SELECT c.CourseName, s.StartDate,  i.FirstName
|| ' '  ||i.LastName as Instructor, l.City
FROM Instructors i   
JOIN ScheduledClasses s ON (i.InstructorID = s.InstructorID)
JOIN Courses c ON (s.CourseNumber = c.CourseNumber)
JOIN Locations l ON (s.LocationId = l.LocationID)
WHERE l.Country = ‘USA'

As you can see, the conditions for joining the tables are now separated from those used to limit down the query.

Jim Czuprynski has put together a good explanation of how ANSI compliant joins work, including step-by-step examples of the various types of natural, equijoins, left, right and full outer joins are put together; in addition, cartesian joins now have to be explicitely defined, which makes them harder to create by mistake.

Jonathon Gennick recently wrote a piece for OTN on ANSI joins and, in his view, one of the key benefits of the new syntax is the support for full outer joins. Previously, full outer joins had to be simulated through using UNION clauses; now they can be explicitely defined in the statement, leading to faster execution and easier to read queries.

One thing to be aware of though is the NATURAL JOIN facility, which allows you to miss off the join condition completely if the tables concerned share common column names on which you want to join. For example, if your STUDENT and CLASS table share a common STUDENT_NO column, you could NATURAL JOIN them thus;

SELECT student_name, class_name
   FROM student NATURAL JOIN class

However, it's ambiguous at best and leaves you open to problems if columns get added or renamed, no more than two tables can be joined using this method, and it gives you little control over the specifics of a join if columns join across the tables in an unusual way. Tom's advice with NATURAL JOINs- forget that they exist.

So which should I use - ANSI joins, or 'traditional' joins? Well, it's down to you in the end. There's no performance benefit or hit by using ANSI joins rather than traditional joins, but by using ANSI joins, your queries are more portable between DBMS platforms, and they're a bit easier to read. In the end, though, it's down to personal preference and whilst there's advantages to the ANSI standard, there's no need to switch if you don't want to.

For more details check out this OTN article, together with this article by Sanjay Mishra for O'Reilly Network on Full Outer Joins in Oracle 9i.



Oracle Training at Sea
oracle dba poster

Follow us on Twitter 
Oracle performance tuning software 
Oracle Linux poster


Burleson is the American Team

Note: This Oracle documentation was created as a support and Oracle training reference for use by our DBA performance tuning consulting professionals.  Feel free to ask questions on our Oracle forum.

Verify experience! Anyone considering using the services of an Oracle support expert should independently investigate their credentials and experience, and not rely on advertisements and self-proclaimed expertise. All legitimate Oracle experts publish their Oracle qualifications.

Errata?  Oracle technology is changing and we strive to update our BC Oracle support information.  If you find an error or have a suggestion for improving our content, we would appreciate your feedback.  Just  e-mail:  

and include the URL for the page.


Burleson Consulting

The Oracle of Database Support

Oracle Performance Tuning

Remote DBA Services


Copyright © 1996 -  2017

All rights reserved by Burleson

Oracle ® is the registered trademark of Oracle Corporation.

Remote Emergency Support provided by Conversational