http://www.sqlservercentral.com/blogs/steve_jones/2010/03/19/be-wary/

Printed 2014/07/25 01:59PM

Be Wary

By Steve Jones, 2010/03/19

We make mistakes when we publish things. It happens, and I am as guilty as some people of mistakenly putting something down on paper that isn’t correct.

Or worse in SQL Server, put something down that applies to one version, and it gets superseded. I don’t usually go back and rewrite things later. I don’t realize I’ve left something out there, or that I’ve forgotten the version. When someone reads it, they might assume it’s correct with my name on it.

However I would like to think that while we have lots of controversial things published, we don’t often put something out there that’s flatly incorrect. I saw this blog post on performance optimization recently and I’ve grabbed a couple images in case it disappears.

badblog_1

badblog_2

The advice given here, while sometimes correct, isn’t necessarily what I’d actually give to developers, or what I think others would give to developers. Some of it appears to be more relevant to SQL 7/2000 and not necessarily something I’d apply to current versions.

Some things are wrong, like “However, if you create a table variable, it only resides in the memory”. This is a common misconception that quite a few people have about SQL Server table variables.

There’s also the “Each time you get a row from the cursor it requires in a network roundtrip, where the normal query makes only one roundtrip. “ That’s not necessarily true. It depends on how you have coded around the cursor. My guess is that this person is either using ODBC cursors, or has seen developers SELECT data from each loop through the cursor. However it seems to display a mis-understanding of how a cursor works.

I point out a couple of items since I think there is some bad advice here, and some very vague advice, that SQL Server people might not want to follow.

To me this is actually good and bad. Perhaps someone out there looking to hire SQL Programmers of Chicago will find my, and other, commentary on this post and decide not to hire them. Or perhaps SQL Programmers will read the interesting Twitter thread on their post (from 3/17/10, about 3:00MST) and decide they should beef up their skills.

Be wary of advice you find on the Internet, whether mine or others. Double check, and above all, test, test, test.


Copyright © 2002-2014 Simple Talk Publishing. All Rights Reserved. Privacy Policy. Terms of Use. Report Abuse.