I have always liked the drawings done by MC Escher.  Looking at his drawings has always forced me to look at things from a different perspective. SQL Server, like his drawings, always gives room for many different perspectives. This is one of mine.

About a year ago,  I was able to present at SQL Saturday #307 in Iowa City, IA.   I gave a session titled “10 Things Every DBA Should Know!”.  The content included such things ranging from “SELECT *” to “AUTOSHRINK” to “Set Based Programming vs RBAR” among others.

After presenting, I looked at my feedback. Something I look forward to post each talk I give. Feedback is important to me as a speaker because I cannot improve if I do not know what is broken.  One comment in particular caught my attention.  It read something similar to this:

“Do more DBA level stuff, and not Dev related stuff”

This to me was great feedback.  I actually made a note to speak to it and explain why I include Dev stuff for future presentations on this particular topic.

While I can completely understand this point of view, I believe that understanding the development aspects of SQL Server are essential in being a good database administrator.  If understanding development related items did not matter, then we wouldn’t care about the quality of code that is developed nor the affects that quality has on SQL Server.

For example, if you don’t pay attention to development related aspects of SQL Server and you ran across this query: “SELECT * FROM dbo.Foo” would you be able to recognize that might be a bad idea?  Of course, it depends on your environment, but in general, this is a bad pattern to have in your databases. Understanding the “whys” are important.

Granted, there might be times where this query would make sense and possibly warranted, but if your table is 326 columns wide (note: that’s not a goal & and they do exist) it’s probably not a good idea.   The query is going to cause increased overhead in a number of areas, such as network bandwidth, disk I/O, etc.

Another example would be scalar functions.  I see a lot of these in my current environment.  Scalar functions can play havoc with the query optimizer.  When this havoc presents itself, usually your SQL Server will reflect accordingly and you’ll see degradation in performance.  If I did not care about the development aspects, I would not be able to recognize the bad pattern and adjust accordingly.

There are probably countless examples that I could use to further drive home the point that as a DBA you should know as much about your SQL Servers as possible.  This includes not only the administration concepts and methods but also the developmental ones.

If you understand both sides of the picture, you will be a much better DBA because of it.