August 13, 2009 at 9:52 pm
Barry, thanks and feel free to complain. I know it's well meant from many of you.
The others, I tend to ignore, or argue if I think I can annoy them more than they annoy me:-D
August 13, 2009 at 9:52 pm
Jeff Moden (8/13/2009)
You've mistaken what I said but, looking back at it, I can see how. I put no words in your mouth or at least I didn't mean to... I said "I don't believe the...". It's an opinion of mine. I appologize for the confusion and the poor choice of words.
Oops, OK, yeah, I see that now. Sorry, old friend. 🙂
[font="Times New Roman"]-- RBarryYoung[/font], [font="Times New Roman"] (302)375-0451[/font] blog: MovingSQL.com, Twitter: @RBarryYoung[font="Arial Black"]
Proactive Performance Solutions, Inc. [/font][font="Verdana"] "Performance is our middle name."[/font]
August 13, 2009 at 9:56 pm
Thanks, Steve, but I'd rather not add any fuel to this particular fire. 😉
[font="Times New Roman"]-- RBarryYoung[/font], [font="Times New Roman"] (302)375-0451[/font] blog: MovingSQL.com, Twitter: @RBarryYoung[font="Arial Black"]
Proactive Performance Solutions, Inc. [/font][font="Verdana"] "Performance is our middle name."[/font]
August 13, 2009 at 10:03 pm
RBarryYoung (8/13/2009)
Jeff Moden (8/13/2009)
You've mistaken what I said but, looking back at it, I can see how. I put no words in your mouth or at least I didn't mean to... I said "I don't believe the...". It's an opinion of mine. I appologize for the confusion and the poor choice of words.Oops, OK, yeah, I see that now. Sorry, old friend. 🙂
It's ok... you've said exactly what I meant but have so poorly worded.
"I'm not going anywhere."
--Jeff Moden
Change is inevitable... Change for the better is not.
August 13, 2009 at 10:27 pm
Considering they are not the norm, my question to you is are the occasional heated discussions, like the one we're talking about, enough to keep you away from SQLServerCentral.com?
No but 16 pages and many structural ANSI SQL definitions that would prevent such future mistakes where not addressed that is the reason I call it lynch mob, someone mentioned UNION but UNION was never connected to Distinct or the JOIN operations. A Groupby without an aggregate function is actually a Distinct and ANSI SQL purists don’t like the ORDERBY because it is a cursor by definition. I am not a T-SQL expert because the article was about stored procedure so I observed. And I am not going away, I am hoping for structured and comprehensive correction because this past one was not.
🙂
Kind regards,
Gift Peddie
August 13, 2009 at 10:40 pm
Heh... I had similar feelings about some of the posts. Some of it was so wrong I was moved to say "I'll also say that a lot of the advice coming up in some of the discussions for this article is just dead wrong, as well." as a comment in the discussion.
Thanks for taking the time to answer my curiosity Gift Peddie. 🙂
--Jeff Moden
Change is inevitable... Change for the better is not.
August 13, 2009 at 10:53 pm
Heh... I had similar feelings about some of the posts. Some of it was so wrong I was moved to say "I'll also say that a lot of the advice coming up in some of the discussions for this article is just dead wrong, as well." as a comment in the discussion.
Thanks Jeff I am sure Steve and Red Gate will implement good solution.
Kind regards,
Gift Peddie
August 13, 2009 at 11:08 pm
Only speaking for myself here, but I think others may agree; for me to leave SSC the sense of Professional Community that currently exists would have to leave the site. There is so much more to SSC than being a strong source of credible information regarding SQL Server and variety of components that make up the product today.
I feel I have made many friends around the world, from South Africa, to Germany, England, and over to New Zealand to mention of few of the places from which many hail. I don't see that on other sites. We have learned much about each other, our interests, even about what some of our children are doing. To leave this, the community would have to leave the site.
I've been a lurker on the other sites, none of them feel like a community of SQL Server Professionals. I have read some nasty replies to questions from some OP's that I know would not be allowed here on SSC. Yes, some of the comments on the discussion of the article that started this thread were a bit harsh, but were done in a professional manner, not in a derogatory or condescending manner. I can only imagine what that discussion would have looked like elsewhere. You thought this was a lynch mob...
Any way, just my 0.02.
August 14, 2009 at 8:22 am
I think you may have missed the where clause in my LEFT JOIN example. All three of these queries will return the same result set. ie Customer records without matching CustomerAddress records.
I noticed that the optimizer creates a slightly different execution plan for the LEFT JOIN query and my question was whether or not anyone knew if it would perform differently than the other two (which have identical plans).
So far only one person responded with a guess that the LEFT JOIN would make better use of indices, but that's not apparent to me when I look at the execution plan. If there is any difference, I'm guessing it's insignificant, but the only way to really know is to do some testing.
With Oracle it is more efficient to use NOT IN than LEFT JOIN and test for IS NULL. Their optimizer uses has a very efficient way of evaluating NOT IN.
I'm not sure about SQL Server, it could be that the data will determine which is quicker.
If you are in doubt it is best to try both on real data and then take the quicker.
Lynn,
I apologise if I offended you or any other person with the lynch mob I should have used different words but I don't agree with the professional part because my take on professional would have answered the two post above and a full list of every entry with relevant correction.
Kind regards,
Gift Peddie
August 14, 2009 at 9:01 am
Gift Peddie (8/14/2009)
I think you may have missed the where clause in my LEFT JOIN example. All three of these queries will return the same result set. ie Customer records without matching CustomerAddress records.
I noticed that the optimizer creates a slightly different execution plan for the LEFT JOIN query and my question was whether or not anyone knew if it would perform differently than the other two (which have identical plans).
So far only one person responded with a guess that the LEFT JOIN would make better use of indices, but that's not apparent to me when I look at the execution plan. If there is any difference, I'm guessing it's insignificant, but the only way to really know is to do some testing.
With Oracle it is more efficient to use NOT IN than LEFT JOIN and test for IS NULL. Their optimizer uses has a very efficient way of evaluating NOT IN.
I'm not sure about SQL Server, it could be that the data will determine which is quicker.
If you are in doubt it is best to try both on real data and then take the quicker.
Lynn,
I apologise if I offended you or any other person with the lynch mob I should have used different words but I don't agree with the professional part because my take on professional would have answered the two post above and a full list of every entry with relevant correction.
Not offended, but considering responses I have read on other sites, what happened here regarding the article that started all of this, it was mild. In addition, the heavy hitters that replied in opposition did so in a professional manner. Some of the other comments may have been less professional, but nothing like I have seen.
August 14, 2009 at 9:22 am
Gift Peddie (8/14/2009)
I think you may have missed the where clause in my LEFT JOIN example. All three of these queries will return the same result set. ie Customer records without matching CustomerAddress records.
I noticed that the optimizer creates a slightly different execution plan for the LEFT JOIN query and my question was whether or not anyone knew if it would perform differently than the other two (which have identical plans).
So far only one person responded with a guess that the LEFT JOIN would make better use of indices, but that's not apparent to me when I look at the execution plan. If there is any difference, I'm guessing it's insignificant, but the only way to really know is to do some testing.
With Oracle it is more efficient to use NOT IN than LEFT JOIN and test for IS NULL. Their optimizer uses has a very efficient way of evaluating NOT IN.
I'm not sure about SQL Server, it could be that the data will determine which is quicker.
If you are in doubt it is best to try both on real data and then take the quicker.
Lynn,
I apologise if I offended you or any other person with the lynch mob I should have used different words but I don't agree with the professional part because my take on professional would have answered the two post above and a full list of every entry with relevant correction.
I don't know - it sounds like a stylistic difference. Telling someone they have some reading and testing to do is no less professional than doing all of the work for the person. The fact is - SQL's optimization is evry situational, so in a way it's a better answer to impress on someone that it may depend on the data, statistics, etc... than to just simply come out and say "IN will always outperform LEFT JOIN in this case".
It's something we all seem to play with: is it better to spoon-feed the OP with completely built answers, or help them along the way to get there. They each have their purpose depending on the setting.
I can only imagine we are all rather busy, so handing out a thesaurus in each answer would drastically reduce how many people get help.
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
August 14, 2009 at 9:45 am
It's something we all seem to play with: is it better to spoon-feed the OP with completely built answers, or help them along the way to get there. They each have their purpose depending on the setting.
I call it either suggestions or may be user added because the thread was to discuss an article posted.
Kind regards,
Gift Peddie
August 15, 2009 at 4:35 pm
Still love the idea of a disclaimer on articles. Glad to hear you are investigating adopting it Steve.
However having come back to the thread after two days I now read a few things related to discussion threads. These threads are clearly OPINION and nothng needs to be disclaimed!
The main point I have really is that if it is presented as fact it should be fact, and if it isn't this should be explicitly and obviously stated.
Tim
.
Viewing 13 posts - 91 through 102 (of 102 total)
You must be logged in to reply to this topic. Login to reply