Login or Sign Up to become a member!
LessThanDot Sit Logo

LessThanDot

Data Management

Less Than Dot is a community of passionate IT professionals and enthusiasts dedicated to sharing technical knowledge, experience, and assistance. Inside you will find reference materials, interesting technical discussions, and expert tips and commentary. Once you register for an account you will have immediate access to the forums and all past articles and commentaries.

LTD Social Sitings

Lessthandot twitter Lessthandot Linkedin Lessthandot friendfeed Lessthandot facebook Lessthandot rss

Note: Watch for social icons on posts by your favorite authors to follow their postings on these and other social sites.

Your profile

    Search

    XML Feeds

    Google Ads

    « Back to business for the SQL Server communitySSRS 05 Passing Multi-Value Parameters Between Reports. »
    comments

    OUTER JOIN order

    by chopstik on Nov 12, 2009 in categories Microsoft SQL Server

    I'm almost embarrassed to publish this but I have operated for years under a false assumption that I only recently discovered to be untrue. Or, to perhaps state it better, to be unnecessary. When using an outer join, I have always tended to put the ON operators in the order of the join itself. So, for example, if my first table in a left join was table1, then my ON operators would always be table1.field1 = table2.field1. A more clear example is below.

    1. SELECT a.[field1], a.[field2]
    2. FROM table1 a LEFT JOIN table2 b ON a.[field3] = b.[field3] AND a.[field1] = b.[field1]
    3. WHERE b.[field1] IS NULL

    However, that is syntactically the same as the following (note where the a.[fieldname] and b.[fieldname] now switch around).

    1. SELECT a.[field1], a.[field2]
    2. FROM table1 a LEFT JOIN table2 b ON b.[field3] = a.[field3] AND a.[field1] = b.[field1]
    3. WHERE b.[field1] IS NULL

    Both of the code samples above do the same thing. The only issue when using an outer join is the order in which the tables are presented, not the operators in the ON part of the join.

    However, that being said, I will still write my code in that fashion as I think it is easier to read and maintain. If nothing else, it is adherence to a standard. So, even if that doesn't match your own standard, it is important to establish a standard and maintain it which will make it easier for future maintenance.

    1904 views
    Instapaper

    10 comments

    Comment from: Christian [Visitor] Email
    Christian I thing you didnt alias table2 as b.
    11/12/09 @ 22:54
    Comment from: tiso [Visitor] · http://tiso.wz.cz/
    tiso You have 3 errors there:
    1. "always be table.field1 = table2.field1" should be "table1.field1 = table2.field1"
    2., 3. "LEFT JOIN table2 ON" should be "LEFT JOIN table2 b ON"
    11/13/09 @ 01:51
    Comment from: chopstik [Member]
    chopstik Thanks for the corrections. I've updated so that they're now fixed.
    11/13/09 @ 06:00
    Comment from: r937 [Visitor] · http://r937.com
    r937 perhaps you should have said "convention" instead of "standard" because "standard" might cause confusion with regards to the SQL standard

    in any case, putting the right table's column first in the ON clause is better because the intent of the join becomes clearer

    clearer because a joined table must always reference a previously-mentioned table, and this previously-mentioned table's column then "sticks out" when the SQL is formatted properly

    clearer also because additional columns line up nicely

    SELECT one.foo
    _____, one.bar
    _____, two,qux
    __FROM one
    LEFT OUTER
    __JOIN two
    ____ON two.one_id = one.id
    ___AND two.fap = 42

    unfortunately because of limitations in this comment box i have had to use underscores to represent spaces, so as to achieve the correct approximate indentation and formatting effect

    anyhow, notice how the "two" columns are all stacked up? and how the "one" column sticks out so that you can visually reference its previously-mentioned table higher up in the code

    clarity in SQL is achieved by indentation, line breaks, and conventions such as this
    11/13/09 @ 06:25
    Comment from: chopstik [Member]
    chopstik That's a good idea, Rudy. I think I had seen someone else mention it (perhaps Emtucifor), too, and I had forgotten but it makes sense to do it that way. And yes, I should have used "convention" and not "standard" but the premise is still the same.

    Thanks for the input!
    11/13/09 @ 06:48
    Comment from: Erik [Member] Email
    Erik Actually, I have the exact opposite opinion. I prefer referring to the other table first.

    Perhaps this is because I generally put one-condition ON clauses on the same line as the table name. The point is that I have to read the joined table name in the first place, so going just a few more characters to find the other table alias is easier than scanning all the way to the end of the line:

    FROM
    TableA A
    INNER JOIN TableB B ON A.ID = B.ID

    Now I'm scanning only a few characters, "B ON A" and I already know which two tables are being joined.
    11/13/09 @ 10:52
    Comment from: henk [Visitor]
    henk I'm using yet another convention; formatting the join so that it really looks like an operator applied to two arguments:

    SELECT
    ___*
    FROM
    ___table1
    ______INNER JOIN
    ___table2 ON (table1.foo = table2.bar)

    Unfortunately, there isn't really any widely agreed upon formatting convention for SQL. Java, C, C++, they all have various widely recognized conventions, but not so for SQL. Basically, every other programmer does it differently and every other such programmer thinks her or her style is the best.
    11/13/09 @ 13:05
    Comment from: Naomi Nosonovsky [Member]
    Naomi Nosonovsky I always list first table first and then the second table, so it would be

    from Table1 T1 inner join Table2 T2 on T1.PkField = T2.FkField

    I also don't use a/b as aliases (even when I write samples) - I like more meaningful names for aliases.
    11/15/09 @ 21:39
    Comment from: Erik [Member] Email
    Erik Naomi, I don't use A and B either except if the table names lend themselves to those letters.

    Henk, I went down the same path you did and like your thinking, but I would never put AND on its own line, so while you're right that INNER JOIN is like an operator applied to two arguments, I still format my JOINs the same way I do my WHERE clauses:

    Condition1
    AND Condition2

    I can't think of a programming language construct that naturally puts an operator on its own line between two operands.
    11/16/09 @ 12:55
    Comment from: vipin [Visitor]
    vipin gr8 stuff and thank u for sharing ur knowledge and define the join Sql statements.

    http://soft-engineering.blogspot.com/
    01/04/11 @ 22:27

    Leave a comment


    Your email address will not be revealed on this site.

    Your URL will be displayed.
    (Line breaks become <br />)
    (Name, email & website)
    (Allow users to contact you through a message form (your email will not be revealed.)