A short post today.
This past weekend I attended another SQL Saturday event. This one in Washington DC. For anyone interested in SQL Server, I highly recommend these events. Typically the cost is just $10 to attend for the day.
I had put in a bid to present but unfortunately was declined. That’s fine, there were plenty of other seminars worth my time to attend.
One of them, Common Coding Mistakes and how to Mitigate Them by William Wolf was a good example of that. @SQLWareWolf did a great job of illustrating a number of fairly common mistakes. That itself was worth the price of admission. But what I really enjoyed was an observation of his, one that I’ve had in the past. As a DBA, I can often spot stored procs written by a programmer with a non-SQL background. The tell-tale is that many (certainly not all) programmers who come to SQL from another background often think in terms of rows, not sets.
An example of this would be the case of a programmer opening up a cursor and looping through the cursor to set the date on a number of records. Of course for any person with a SQL background, we understand that can be a single statement which will execute far faster.
Now, there are certainly times when row by row is the only way to do it, but if you see that in a sproc or script, I’ll bet you 5:1 it was written by a programmer who didn’t know better.
Now, to be fair as a DBA who learned to program when “object oriented” wasn’t a buzz-word, I’ve been doing a lot of VB.net programming lately and I have to admit often I’ll find myself down a hole of twisty paths before I’ll realize I’m writing bad code and if I simply think of the data I’m trying to modify as an object, suddenly things get FAR more clear and easier. I would not be surprised if 5 years from now the next programmer comes along, looks at my code and thinks, “What was he thinking? He obviously understood objects, but didn’t do everything he should have using objects.”
But in both cases, over time the non-SQL programmer coming to SQL will learn and I hope my OO code is slowly getting better.
No real moral here other than common observations and that hopefully overtime, we all improve.