Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 

The Voice of the DBA

Steve Jones is the editor of SQLServerCentral.com and visits a wide variety of data related topics in his daily editorial. Steve has spent years working as a DBA and general purpose Windows administrator, primarily working with SQL Server since it was ported from Sybase in 1990. You can follow Steve on Twitter at twitter.com/way0utwest

Be Wary

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.

Comments

Posted by Jason Brimhall on 19 March 2010

Agree on the test, test, test.

There is plenty of evidence of bad advice - or well intentioned advice that is wrong.

Thanks for the heads up.

Leave a Comment

Please register or log in to leave a comment.