| Author |
Topic |
|
rajani
Constraint Violating Yak Guru
367 Posts |
Posted - 2007-12-03 : 20:02:39
|
| Hiam 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 isms-help://MS.SQLCC.v9/MS.SQLSVR.v9.en/udb9/html/faf5a9a8-abe5-4d2c-b333-582bce4e28d6.htmCheers |
|
|
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 BA left outer join B on ...gives you all A and any matching rows from B or nullsB left outer join B on ...gives you all B and any matching rows from A or nullsWhich 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. |
 |
|
|
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 wasI'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 |
 |
|
|
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. |
 |
|
|
SwePeso
Patron Saint of Lost Yaks
30421 Posts |
|
|
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. |
 |
|
|
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" |
 |
|
|
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 statementSELECT [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 |
 |
|
|
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 queryCheers |
 |
|
|
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. |
 |
|
|
|