<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	>
<channel>
	<title>Comments on: SQL SERVER - Effect of Order of Join In Query</title>
	<atom:link href="http://blog.sqlauthority.com/2008/08/02/sql-server-effect-of-order-of-join-in-query/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.sqlauthority.com/2008/08/02/sql-server-effect-of-order-of-join-in-query/</link>
	<description>Notes of a SQL Server MVP and Database Administrator</description>
	<pubDate>Wed, 07 Jan 2009 20:20:58 +0000</pubDate>
	<generator>http://wordpress.org/?v=MU</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: ethan</title>
		<link>http://blog.sqlauthority.com/2008/08/02/sql-server-effect-of-order-of-join-in-query/#comment-45194</link>
		<dc:creator>ethan</dc:creator>
		<pubDate>Tue, 30 Dec 2008 09:02:28 +0000</pubDate>
		<guid isPermaLink="false">http://sqlauthority.wordpress.com/?p=767#comment-45194</guid>
		<description>Hi!
Nice article.. 

talking bout joins is there a way to join these two result sets :

TABLE 1

DATE
01/01/2008
02/01/2008
03/01/2008

TABLE 2
DATE                    EMP
01/01/2008          123
02/01/2008          123
03/01/2008          456

with condition of Emp='123'

into these
RESULTS:

DATE                   EMP
01/01/2008        123
02/01/2008        123
03/01/2008        NULL

thanks...</description>
		<content:encoded><![CDATA[<p>Hi!<br />
Nice article.. </p>
<p>talking bout joins is there a way to join these two result sets :</p>
<p>TABLE 1</p>
<p>DATE<br />
01/01/2008<br />
02/01/2008<br />
03/01/2008</p>
<p>TABLE 2<br />
DATE                    EMP<br />
01/01/2008          123<br />
02/01/2008          123<br />
03/01/2008          456</p>
<p>with condition of Emp=&#8217;123&#8242;</p>
<p>into these<br />
RESULTS:</p>
<p>DATE                   EMP<br />
01/01/2008        123<br />
02/01/2008        123<br />
03/01/2008        NULL</p>
<p>thanks&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Chris Schaller</title>
		<link>http://blog.sqlauthority.com/2008/08/02/sql-server-effect-of-order-of-join-in-query/#comment-41548</link>
		<dc:creator>Chris Schaller</dc:creator>
		<pubDate>Sun, 10 Aug 2008 20:37:55 +0000</pubDate>
		<guid isPermaLink="false">http://sqlauthority.wordpress.com/?p=767#comment-41548</guid>
		<description>Although I do find this issue interesting, even as a thought exercise I don't find it useful... yet.

I was expecting this article to explore the effect of the order of join statements in a query and how the order might be best used to optimise it.</description>
		<content:encoded><![CDATA[<p>Although I do find this issue interesting, even as a thought exercise I don&#8217;t find it useful&#8230; yet.</p>
<p>I was expecting this article to explore the effect of the order of join statements in a query and how the order might be best used to optimise it.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jacob Bennett</title>
		<link>http://blog.sqlauthority.com/2008/08/02/sql-server-effect-of-order-of-join-in-query/#comment-41544</link>
		<dc:creator>Jacob Bennett</dc:creator>
		<pubDate>Sun, 10 Aug 2008 16:07:18 +0000</pubDate>
		<guid isPermaLink="false">http://sqlauthority.wordpress.com/?p=767#comment-41544</guid>
		<description>Hi Pinal.  I like this article/question!

Here is what I think:
I believe it is the way the join operators organize the rows when joining the two tables together.  In the "outer join" query  the execution plan shows hash match operators, if you change the hash match operator to nested loop on EmployeeDepartmentHistory and Department you get the same ordered result set as the "inner join" query.

I don't know enough about how hash match join to comment on why it yeilds a different order than nested set so maybe someone can help me with that.

Here is the modified "outer join" query that yeilds the same ordered result set as the "inner join" query.

SELECT he.EmployeeID, he.Title, hd.Name, hd.GroupName, hdh.StartDate
FROM HumanResources.Employee he
LEFT JOIN HumanResources.EmployeeDepartmentHistory hdh
ON he.EmployeeID = hdh.EmployeeID
RIGHT JOIN HumanResources.Department  hd 
ON hd.DepartmentID = hdh.DepartmentID OPTION (LOOP JOIN)</description>
		<content:encoded><![CDATA[<p>Hi Pinal.  I like this article/question!</p>
<p>Here is what I think:<br />
I believe it is the way the join operators organize the rows when joining the two tables together.  In the &#8220;outer join&#8221; query  the execution plan shows hash match operators, if you change the hash match operator to nested loop on EmployeeDepartmentHistory and Department you get the same ordered result set as the &#8220;inner join&#8221; query.</p>
<p>I don&#8217;t know enough about how hash match join to comment on why it yeilds a different order than nested set so maybe someone can help me with that.</p>
<p>Here is the modified &#8220;outer join&#8221; query that yeilds the same ordered result set as the &#8220;inner join&#8221; query.</p>
<p>SELECT he.EmployeeID, he.Title, hd.Name, hd.GroupName, hdh.StartDate<br />
FROM HumanResources.Employee he<br />
LEFT JOIN HumanResources.EmployeeDepartmentHistory hdh<br />
ON he.EmployeeID = hdh.EmployeeID<br />
RIGHT JOIN HumanResources.Department  hd<br />
ON hd.DepartmentID = hdh.DepartmentID OPTION (LOOP JOIN)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Nicholas Paldino [.NET/C# MVP]</title>
		<link>http://blog.sqlauthority.com/2008/08/02/sql-server-effect-of-order-of-join-in-query/#comment-41307</link>
		<dc:creator>Nicholas Paldino [.NET/C# MVP]</dc:creator>
		<pubDate>Mon, 04 Aug 2008 14:55:59 +0000</pubDate>
		<guid isPermaLink="false">http://sqlauthority.wordpress.com/?p=767#comment-41307</guid>
		<description>I think it should be stressed that this should be taken as a thought exercise and not used in lieu of an ORDER BY statement.

If an ORDER BY statement is not used, then the order is undefined.  You might be able to predict it, but to base code/logic on it is a bad, bad thing to do.</description>
		<content:encoded><![CDATA[<p>I think it should be stressed that this should be taken as a thought exercise and not used in lieu of an ORDER BY statement.</p>
<p>If an ORDER BY statement is not used, then the order is undefined.  You might be able to predict it, but to base code/logic on it is a bad, bad thing to do.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
