T-SQL Tuesday: Why are DBA Skills Necessary? – A Datachix Perspective

I have a few confessions to make: I encourage my son to watch Phineas and Ferb because I secretly enjoy it. Jersey Shore is strangely entertaining. I claim that I don’t sing, but if you ever see me alone in my car on I-85, I’m probably wailing away. I read all four Twilight books. I have a crush on Nathan Fillion.  And… lean closer… I’m going to whisper this one: I’m not a DBA.

My resume would say otherwise. I can point to multiple job titles throughout my career that have the words “Database Administrator” in there somewhere. Guess what? I’ve never been a DBA, and if pressed, I’d call myself a Developer. Now, I’ve made peace with this. I love what I do, and I’m pretty good at it, even if it is difficult to explain to non-technical people the difference between being a DBA and a Developer. I think the confusion comes from the fact that there are so many job titles, and they’re all kind of vague. People assume that if you work with data you’re a DBA. They assume that we all have the same skill set. The truth is so much more complicated.

See, there is a LOT of specialization out there. I’m currently a BI Consultant. Before that, I was a Data Architect, doing BI work. Before that, I was a “DBA”, developing relational databases. But, at the end of the day, I’ve got a specialization. I model and develop databases, and I move data around. Over the past few years, I’ve started traversing the BI stack, but at the end of the day, I’m really just a Database Developer. The simple truth is that there are so many angles and disciplines within the data universe, you have to be specialized. To borrow a silly cliché, anything else would be drinking from the fire hose. You’d get soaking wet, and you’d probably still be a little thirsty.

So, to the point. Paul Randal raised some great questions for this T-SQL Tuesday, “Why are DBA Skills Necessary?” I want to focus on a sub-topic he suggested, “Should there be cross-over between developer skills and DBA skills?” On the surface, the answer is an obvious, “Yes!” It was for me too, until I actually sat back and thought about it. My new answer is, “Yes, to a point.” See, asking me, a non-DBA, to attempt to be a DBA is like asking a psychiatrist to perform heart surgery. Yes, they both went to medical school, and yes, the psychiatrist could probably hold up his end of the conversation with a heart surgeon, but really, would you want him to cut on you? Probably not.

Here is my perspective: I need to be aware of what’s going on within the Database Administration universe. It’s why I attend both the Atlanta MDF, which is largely DBA-focused, and the BI User’s Group. I read blogs, books, and articles related to the entire data universe, not just my specialization. In fact, there are many, many things DBA’s do that I wish I knew better. I need to have a good vocabulary in the discipline, and I need to be able to carry on intelligent conversations with DBA’s. Does this mean that you should trust me to be your DBA? Probably not. By the same token, I also see application development in the same way. I should be able to discuss application development intelligently, but I don’t really know how to do it properly. Don’t get me wrong… I’m competitive enough that I want to be an expert at everything, but I’m also realistic to know that I’m never going to.

See, to lump us all into one “DBA” bucket is to diminish the amazing job that so many DBA’s do every day. To pretend that I could step into a server room and hold my own unassisted is not only arrogant and delusional, it is dangerous.

Which brings me to the next point…

“At what point does a SQL Server installation need a DBA to look after it?” Immediately! Friends, your DBA is not just the chick who does backups and restores. You know how developers complain about not being brought into the development cycle early enough? Like when requirements are being created? Well, how does the DBA feel? We pretend that we understand the DBA discipline, and muck around in our development environments, making wild assumptions based on test data sets. Then, just before going to production, we dump an entire environment on the DBA and ask her to make our hot mess of a product perform well. Even worse, we act like that annoying taxi passenger telling the driver to take the Connector instead of the Perimeter because its 5:17 on a Friday and we think we’ve got Atlanta traffic down to a science. Like I know more about how to get around the city than the guy who does it for a living? Right.

Good DBA’s, and I’ve been lucky enough to work with quite a few over the years, know as much or more about the business being served by the database as the rest of the development team. That’s a key point… The DBA is part of the development team. Business requirements translate into administrative requirements, so get that DBA in the room early and often! And if you’re lucky, by hanging out with the DBA more, you’ll learn a thing or two about her side of the world.