Please start any new threads on our new site at https://forums.sqlteam.com. We've got lots of great SQL Server experts to answer whatever question you can come up with.

 All Forums
 SQL Server 2005 Forums
 Transact-SQL (2005)
 order of the tables in join

Author  Topic 

rajani
Constraint Violating Yak Guru

367 Posts

Posted - 2007-12-03 : 20:02:39
Hi
am reading "Using Joins" section under books online and i found following

"The tables or views in the FROM clause can be specified in any order with an inner join or full outer join. However, the order of tables or views specified when using either a left or right outer join is important. For more information about table ordering with left or right outer joins, see Using Outer Joins."

i checked "using outer joins" section but cant find any mention of order of tables in there!
can anyone explain why order is important and what it should be ?
Thanks for the advise.

the BOL link is
ms-help://MS.SQLCC.v9/MS.SQLSVR.v9.en/udb9/html/faf5a9a8-abe5-4d2c-b333-582bce4e28d6.htm

Cheers

LoztInSpace
Aged Yak Warrior

940 Posts

Posted - 2007-12-03 : 20:50:49
The orderness is important when you go outer because the query will fill in missing values for you. Imagine A and B
A left outer join B on ...
gives you all A and any matching rows from B or nulls
B left outer join B on ...
gives you all B and any matching rows from A or nulls
Which is likely to be a completely different set of data. That's why it's important.

An inner join where both tables must match to produce a row it makes no difference. The optimiser will take care of which table to drive the query so don't listen to any bullshit about putting them in any particular order for best performance.
Go to Top of Page

rajani
Constraint Violating Yak Guru

367 Posts

Posted - 2007-12-03 : 21:06:33
very well explained, thank you very much for that,LoztInSpace. that makes sense.
Probably you can help with something else here ,the reason i was reading this BOL chapter was

I've this stored procedure which a simple SQL and returns the data as expected. Today I was investigating query plan to see if there is anything I can do to speed it up a bit. What I noticed is a warning in execution plan that says "No Join Predicate" !

My question is ,what is join predicate ? Do I need to change my query at all to fix this warning ?
As I mentioned above the SP returns data correctly .
Please let me know if you need any further info to advise me on this.


Cheers
Go to Top of Page

LoztInSpace
Aged Yak Warrior

940 Posts

Posted - 2007-12-04 : 02:38:16
If it returns what you want then there is not necessarily anything wrong with it. What you describe means you may unintentionally be doing a cross join. Typically the optimiser can turn the various ways of achieving the same thing into a common execution plan provided it has enough information (constraints & relationships, statistics). Sometimes an incorrect query can just work because the data is such that no errors reveal themselves. Using 'distinct' to 'fix' a query is often another give away that the query is fucked but distinct 'seems to fix it'
Without the query, table sizes and definitions it is is hard to tell if there is a better way but it is not necessarily wrong. If it is large data and very slow then I am guessing you have an undeclared relationship, a missing index or a broken query 'fixed' with distinct. Post what you have and someone will look at it I am sure.
Go to Top of Page

SwePeso
Patron Saint of Lost Yaks

30421 Posts

Posted - 2007-12-04 : 03:28:50
The order of JOINs are always important. This is how SQL Server decides which type of JOIN to perform.
See http://blogs.msdn.com/craigfr/archive/2006/08/16/702828.aspx



E 12°55'05.25"
N 56°04'39.16"
Go to Top of Page

LoztInSpace
Aged Yak Warrior

940 Posts

Posted - 2007-12-05 : 01:57:45
That's not quite what I got from the article. I agree that when the tables are absolutely 100% identical in every way, the query plan may well somehow use the order of tables (it has to make its decision somehow) but in this case it is clearly unimportant. Once there are differences such as indexes, statistics and the like then the optimiser takes over and you can move the order around as much as you like and you still get the same query plan (notwithstanding my comments on outer joins of course).
If this were not the case then the FORCE ORDER hint would not exist.
You can prove this yourself by running all the examples in the article swapping T1 & T2. You will find the plan reflects the table order until the steps changes one of the tables by adding an index. From then on, the plans are always the same whichever order you join them. Alternatively take the identical tables T1 & T2 and add 20 rows to one of them. You will now get an identical plan for all queries whichever order you join them in, no doubt because the slightly larger table can influence the effiency of the plan.

Go to Top of Page

SwePeso
Patron Saint of Lost Yaks

30421 Posts

Posted - 2007-12-05 : 03:22:45
I agree the plan is the same. I was talking about the TYPE OF JOIN the query engine was selecting.



E 12°55'05.25"
N 56°04'39.16"
Go to Top of Page

rajani
Constraint Violating Yak Guru

367 Posts

Posted - 2007-12-05 : 14:42:58
Thank you both for your comments.
I tried DISTINCT but still get the no predicate warning. btw this is sql statement

SELECT [mast].[SURNAME],[mast].[FirstNames],
dd.[Date of Birth],
[mast].[bldgbox],[mast].[sex],
[mast].[type],COALESCE([ut].[postcode],'') AS [postcode],COALESCE([ut].[name],'') AS [TownName],
[pn].[DVA Number],
[pn].[Medicare Card Number],
[pn].[Medicare Number Suffix],
[mast].[altsurname] AS [SurnameAlias],
[mast].[knownname] AS [FirstnameAlias],
[pat].[hpolicy] AS [HealthFund_Member_No],
[pn].[War Pension Number] AS [Fund Upi No],
[provnum].[number] AS [ServiceProviderNumber],
[prv].[firstnames] AS [ServiceProvider_FirstName],
[prv].[surname] AS [ServiceProvider_Surname],
[hinsurer].[brandid] AS [HealthInsurer_Brandid],
[pat].[hpolicy] AS [FundMembershipNumber]
FROM dbo.[u_master] AS mast
LEFT OUTER JOIN dbo.[dd_Patient_Numbers] AS pn ON [mast].[MASTERID] = [pn].[MASTERID]
LEFT OUTER JOIN dbo.[dd_Demographic_Details] AS dd ON [pn].[MASTERID] = [dd].[MASTERID]
LEFT OUTER JOIN dbo.u_town AS ut ON [mast].FK_TOWN_TOWNID = ut.TOWNID
INNER JOIN dbo.[u_patient] AS pat ON mast.[masterid] = [pat].[fk_master_masterid]
LEFT OUTER JOIN dbo.[u_provnum] AS provnum ON mast.[fk_leadprov_providerid] = [provnum].[fk_provider_providerid]
LEFT OUTER JOIN dbo.[u_provider] AS prv ON [provnum].[fk_provider_providerid] = [prv].[providerid]
LEFT OUTER JOIN [dbo].[u_org] AS hinsurer ON [pat].[fk_hinsurer_masterid] = [hinsurer].[fk_master_masterid]
WHERE [mast].[MASTERID] = @patientId

Cheers
Go to Top of Page

rajani
Constraint Violating Yak Guru

367 Posts

Posted - 2007-12-05 : 15:04:33
btw all objects start with "DD_" are views and others tables in the above query

Cheers
Go to Top of Page

LoztInSpace
Aged Yak Warrior

940 Posts

Posted - 2007-12-05 : 16:18:19
quote:
Originally posted by Peso

I agree the plan is the same. I was talking about the TYPE OF JOIN the query engine was selecting.



E 12°55'05.25"
N 56°04'39.16"



Again, I didn't get that. The type of join varies by the nature of the query, not the order of the tables. No matter.

rajani: Without looking into the views it is hard. All those outer joins make for very few options for the optimiser. If they absolutely must be outer joins (i.e. there can be missing data) you're basically doing all you can other than look at the individual views.
Go to Top of Page
   

- Advertisement -