Take a typical left outer join scenario. We all know that the order of the tables is quite significant, e.g., Q1 and Q2 are not equivalent:
SELECT A.x, B.y FROM A LEFT OUTER JOIN B ON A.id = B.id -- (Q1)
SELECT A.x, B.y FROM B LEFT OUTER JOIN A ON B.id = A.id -- (Q2)
When I think conceptually about multiple joins it usually seems natural to me to imagine picking up the new table as the object of interest and then describing how its rows are related to what’s come before. Keeping the terms in parallel doesn’t have any advantage to me and by my own habit I generally write the join condition this way:
SELECT A.x, B.y FROM A LEFT OUTER JOIN B ON B.id = A.id -- (Q3)
I had a conversation with a former coworker who misunderstood how the syntax works. To this coworker, Q3 was wrong and Q1 was right. And I do recognize that with the old-style outer join syntax this would matter and that’s likely the source of this confusion. I’ve never heard or seen anyone else make this case using ANSI joins. Please answer this question and redeem my reputation, point out something I’ve overlooked, or offer deeper insight into the erroneous perspective.
Does the order of expressions or predicates make any difference in the join condition for outer joins in standard SQL with ANSI joins?
No, it makes no difference.
Personally I prefer the style that you show in Q3, some of my workmates prefer the style in Q1. I don’t know anyone who would ever consider either of them to be wrong.
The query optimiser turns the query inside out into something completely different, so the predicate doesn’t even exist as a plain comparison any more when it’s done with it. Usually it’s a lookup in an index or a table, and as that can only be done in one direction, how the predicate was written makes no difference.
I checked (in SQL Server 2005) the execution plan of two queries with the predicate operands in different order, and as expected they are identical.