Your thoughts about my intent of the example are correct. I never even thought about the possibility to misinterpret it the way you fear 'newbies' might. But I do understand your point. The key line I think is this one:
"...SQL Server will not reuse the execution plan for statements specifying differently qualified object names"
I see now that I might have been able to write that in a more explicit (no pun intended) way. What I of course meant was something like "...even if the only difference between query A and query B is the qualification of owner names, when executing query B SQL Server will not reuse the execution plan of query A". Maybe I could have also explicitly (again [
]) stated that also the execution plan for query B will be reused if it is executed again, just as the one for query B. It would just have been an extra execution in the sample script so that would probably have been a good idea. But I must admit that I have no intention of writing articles intended for absolute beginners, I think it is more interesting and appealing to a larger audience to raise the level a bit. Therefore I hope that most readers will understand the part regarding defaults and how these will be used for cache reuse. Finally, the main intent of the article was not at all to point at the performance gains you can get by qualifying objects with owner name, but rather to show that there are several good reasons to do it and none other than laziness not to do it.
In any way, I do not see how this advice can be wrong for anyone, newbie or seasoned veteran. Yes, there are some arguments to be made regarding code reusabilty (as stated in earlier messages in this thread), but I think there are other ways to handle those situations. And no matter how much a worst practice, there are of course always some kind of exception to anything. But as I said in the article, the only reason (except for the above) to not qualify objects with owner names is laziness. Or if you turn it around, if you do not have a reason not to qualify them, why should you then not do it?
Chris Hedgate http://www.hedgate.net/Contributor to the Best of SQL Server Central volumes