Editorial - Lazy Developers - Database Weekly (2008/07/28)
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 from [SQLServerCentral]Create?.com
Source:
Fresh copy to be cached until 6:27:57 PM |
