Other than that, ANSI style doesn’t add any benefit at all. Some people say it’s easier to read, but I just disagree. There’s also the old argument of Standards, but again, not a single databases vendor can claim to be 100% fully ANSI compliant and thus no 2 databases are ever going to be the same (unless Oracle takes them over!), so unless you think you can move from DB1 to DB2 without having to learn DB vendor specific features, it’s just pointless.

I concur with Doug’s post of 6/12. It is sometimes necessary to include filtering in the join clause. Often for clarity’s sake this is done in an inline view. Using Doug’s example:

SELECT d.dname, d.deptno, e.ename
FROM dept d LEFT OUTER JOIN emp e
ON d.deptno = e.deptno and
e.name like ‘M%’;

is the same as:

SELECT d.dname, d.deptno, e.ename
FROM dept d LEFT OUTER JOIN
(select deptno, ename from emp
where ename like ‘M%’) e
ON d.deptno = e.deptno;

I know I’m repeating myself here, but still not sure how an experienced sql coder can easily make the mistake of thinking that “left” table filtering conditions in the ON clause of a left outer join would have an effect though, as the fundamental contract of a left outer join is that rows from the “left” table that don’t meet the joining conditions WILL still appear in the result set.

So to even an experienced SQL coder, it’s easy to make the mistake that a filter on the left-side table would also take effect, but it doesn’t.

It’s not at all about comparing apples and oranges. It’s about syntax that doesn’t change the result set with a JOIN can very well change the result set with an OUTER JOIN because it changes the meaning of the query. I agree 100% with your comments about good practice. The facts are that many people do not realize this (as I’ve seen this issue in a number of organizations) hence the whole reason I wrote this post: to educate and inform.

Cheers.

With respect, is that argument not akin to comparing “apples and oranges” ? – an apple is green, but that doesn’t mean that it is confusing that an orange isn’t green, because an apple isn’t an orange.

Likewise, a regular join isn’t a left outer join, and it doesn’t have the characteristics of one.

The fundamental contract of a regular join is that rows that don’t meet the joining conditions WILL NOT appear in the result set. So when you add “d.deptno in (10,40)” to the joining conditions of your regular join it means that you DO NOT then see rows that don’t meet that condition in your result set.

The fundamental contract of a left outer join is that rows from the “left” table that don’t meet the joining conditions WILL still appear in your result set. So when you add “d.deptno in (10,40)” to the joining conditions of your left-outer join you DO still see rows that don’t meet that condition in your result set.

I think this is a helpful thread and I agree that there is plenty of scope for someone to inadvertently produce results they didn’t intend by incorrectly using these constructs, problems relating to which can be entirely avoided by what I would consider the good practice of putting only true joining conditions in the on clause and putting filtering conditions in the where clause.

Anyway, thanks for the interesting site Greg.

I believe the reason there is confusion is that with regular joins this is not observed.

For example:

SELECT d.dname, d.deptno, e.ename
FROM   dept d JOIN emp e
ON     d.deptno = e.deptno
WHERE  d.deptno in (10,40)
/

DNAME		   DEPTNO ENAME
-------------- ---------- ----------
ACCOUNTING	       10 CLARK
ACCOUNTING	       10 KING
ACCOUNTING	       10 MILLER

3 rows selected.

SELECT d.dname, d.deptno, e.ename
FROM   dept d JOIN emp e
ON     d.deptno = e.deptno
AND    d.deptno in (10,40)
/

DNAME		   DEPTNO ENAME
-------------- ---------- ----------
ACCOUNTING	       10 CLARK
ACCOUNTING	       10 KING
ACCOUNTING	       10 MILLER

3 rows selected.

Yes of course moving the condition from the where clause to the on clause changes the semantics, but my point was why would one not expect that to be the case? If doing this didn’t change the semantics then it would have broken what fundamentally a left outer join means – now that would be confusing!