If you have read these editorials for any length of time, you might know I like to pick on developers. It's a gross generalization and there are some great developers out there, but my views as developers causing most of the problems in software are not without some basis.
I think that most developers are naturally inquisitive and they like to solve problems. Computers give them the ability to shape the virtual world as they see it, in a way that many people can't do in the physical world. I think many developers are also lazy, using the power of computers through programming, macros, scripts, etc. to get work done quickly and avoid boring, repetitive tasks.
So why don't they spend time using the power of their applications to solve performance problems? This great blog post on "converting input at the client" is a great one, and one that I think shows where the laziness of developers comes back to haunt them.
I know that writing database code isn't something many developers want to do, or even learn to do. I've seen that written over and over, and I constantly see developers complaining about writing data access and SQL code. I guess that's one of the reasons that LINQ was developed. However that's not an excuse to avoid doing things correctly.
Take the time to shoulder the burden of data conversion, validation, checking, etc. on the client side. There's one database server for more application servers (if you use them), many more web servers, and even more client-side code, which means the database is the least scalable component of an application in many cases. Not that we can't throw more horsepower at the database server, but when it comes down to it, there are many more spare cycles on clients than the servers, especially the one server that's difficult to scale out.
Writing this code to convert dates and numbers to their proper types isn't fun or sexy, but it's easy to do and getting in the habit of doing that, just like getting in the habit of using stored procedures, parameters, etc. make a much more scalable application. And they make one that's easier to develop. Would you rather step through code on your client application to figure out what wrong or have to move back and forth between the application and the server in a debugger?
I partially blame the authors of so many articles on applications that access data. Showing short, quick samples that use dynamic SQL, don't convert dates, etc. just perpetuates the poor habits that many developers pick up. My view is that sample code should be production quality. If you don’t want to explain the error checking or conversions because they're not the focus of your writing, gloss over them. Even if the reader doesn't understand them, the clipboard will move them over when someone "borrows" your code.
Steve Jones
Steve's Pick of the Week
A New Competitor? - SQL Server was spawned from Sybase and has outgrown its parent. However Sybase is the closest product to SQL Server, both sharing T-SQL as a common language, although each platform has evolved the language away from the other. Sybase has posted nice gains in its business, something that 10 years ago I would have not have believed possible, thinking they were heading out of business. If your company requires a *nix based solution for a database server, I might really push them to look at Sybase and leverage some of your current SQL Server skills on this platform.
Steve Jones
The Voice of the DBA Podcasts
The podcast feeds are now available at sqlservercentral.podshow.com to get better bandwidth and maybe a little more exposure :). Comments are definitely appreciated and wanted, and you can get feeds from there.
or now on iTunes!
- Windows Media Podcast - 48.9MB WMV
- iPod Video Podcast - 36.4MB MP4
- MP3 Audio Podcast - 7.4MB
Today's podcast features music by Incompetech. Kevin Macleod has some great compositions in all genres of music. Check him out at www.incompetech.com.
I really appreciate and value feedback on the podcasts. Let us know what you like, don't like, or even send in ideas for the show. If you'd like to comment, post something here. The boss will be sure to read it.