I liked the author's approach except there are also some other factors that should be considered as other replies have alluded to. Any Database Administrator must also consider the impact of any given logical model to the physical model of the database. This can indeed affect performance and in turn other problems when business units have to wait several minutes to get one simple report. A DBA may have all the DBCC commands memorized but may not understand the impact of having both the log and data files on the same disk array. Also in terms of normalization a DBA worth their salt must also know when to use denormalization and understand the two models of data warehousing and when to apply these models.

I myself have worked many years in the Database Administration field and have noted that these days most of the organizations I have worked for or have visited the developers are now picking up the task of DBA as well. These shops are mostly MS SQL based however opposed to Oracle and DB2 shops where the DBA's are separated from the developers which I personally prefer. The current organization I work with identified the developers as the DBA's. Thus to find a pure MS SQL DBA which duties is purely a DBA may be limited. As for myself, I am trying to move on and focus on being more involved with the business units to better leverage IT to accomplish organizational short and long term goals.

As a side note, I am a Senior Software Engineer who is also one of three DBA's for the shop I work within. So for the folks looking for a pure MS SQL DBA I say good luck. They may indeed be out there, but I suspect they are wearing more than one hat these days. I myself have just finished an SQL 2000 to SQL 2005 conversation which was an experience all into itself I must say. None the less the above are my own view and may not apply to all shops.

Thank you;

Codexena