I blogged about developers and sysadmins working collaboratively a few weeks ago, but I didn’t even touch upon the unique role of a database administrator. In coding and scripting, the best engineers can deliver efficiency efficiently. The principal difference between gurus and those who are starting out is that the guru can do everything faster, with fewer lines of code, and in a more bulletproof fashion. As we develop experience, we start to marvel at how a few hours of thinking resulted in 10 lines of code wheras we used to write and rewrite hundreds of lines of code to accomplish the same thing.

Database work is even more “magical,” in the sense that the developer is forced to work in a very “tight” workspace from the beginning. Few things work well iteratively–I mean, yes, you can declare a cursor, then parse through the result set line by line…but this typically KILLS performance. Most of the time, there is one command or a series of clever data manipulations that require thinking of the data as an abstraction, as a set of records. For example instead of scripting an iterative process of updating rows in a table, the database developer might constuct a correlated subquery. The end result of your efforts may be ten lines of code, but read the mysql tips here first, then consult the enhancements in mysql 6.0 or review Microsoft’s approach…and after all that, you may conclude a cursor is better after all!

Working with databases is a mixture of art and science and because there are so many different ways to do things. It is difficult to categorically state one approach as better than another–and the learning process never ends.