Who Is Responsible For What?

In my previous life I was a production DBA which meant my primary responsibility was recovery. I also took my job role to be that of a general SQL Server expert. I stayed general because no one person can possible be an expert in every facet under the SQL Umbrella. A few years ago I had my team start to specialize in different areas, so that we would have some deeper expertise in something like SSRS, but our primary responsibility remained with being able to recover. We were never asked to take part in database design, we were never asked to take part in anything, really. We were just told to fix things when they broke. That meant we needed to know a little bit about a lot of different things.

This morning I was reading up on row versioning (what? like you weren’t doing the same?) over at http://msdn.microsoft.com/en-us/library/ms345124.aspx and I came across this statement:

“The database administrator for a system is responsible for evaluating the impact on the system and applications of either of the row versioning–based transaction isolation schemes. The developer is responsible for understanding how to exploit the new isolation-level behaviors to build better applications.”

Wait a minute there…the developer is responsible for something? Do they know this? Has anybody told them yet?

So, let’s back up for a second here. Go and read a recent article by Brian Moran titled “Is There a Shortage of SQL Server Experts”. The title suggests one thing, “experts”, but then shifts to talk about a shortage of DBAs, and I’m not sure he meant to use that label but maybe he did.

Well, what about the developers? Shouldn’t they be experts as well?

My experience has been that the DBA is expected to be the expert in the shop, and that they need to play the Superhero role and come in at the 11th hour to explain everything in depth in terms that everyone (even managers) can understand. That ain’t easy. Worse still is when a developer spends eight months building something that doesn’t scale beyond the 100 rows they “tested” against and when you tell them they need to rethink their design you are met with something like “stop blaming my code, it isn’t the code!” (dude, yes it is, now sit down and shut up, I’m the expert here.)

So, who does what in your shop? Do your developers know that they should have an understanding of what row versioning is, and how it can be applied to build better applications? Or are you expected to know such concepts and to teach it to developers as well?

There are always a lot of new things to learn with SQL Server, but who in your shop is taking the time to stay on top of everything?

http://www.seangallardy.com Sean Gallardy

We are the same type of setup, fix it if it’s not working. On the other hand, everyone comes to us for advice, even on setting up windows servers and linux questions. We’re not only DBAs here, but NetAdmins, Server Hardware guru’s, etc.

On the Developers note, we’re constantly tuning their queries… it almost seems that developers are very very junior dba’s.

Thomas LaRock

exactly. so, when CIOs complain that there are no SQL experts, shouldn’t they look at their training budgets and hiring practices?

Joseph D’Antoni

Tom–great post. I feel like the general lack of developer database expertise happens, because dev operate in so many spaces, that they never really specialize in one. What I really hate, is the 3rd party applications, that have really crappy database designs that you are stuck with.

Through relationship building, I can work and help my local devs write better database code. I can’t do that for a 3rd party.

Thomas LaRock

Joseph – great point! i forgot about crappy vendor code…did i say that out loud? Anyway, yeah, everyone is stuck with that part. And if devs are pulled in many directions, as well as DBAs, then what can be done to reduce the fear that there are not enough SQL Server experts?

Chaka Khan

I believe mauve has the most ram.

Thomas LaRock

i believe you are right. and i like my databases blue.

http://adventuresinsql.com Dave Levy

Great post!

I hear so much talk about the division of duties between devs and dbas and it drives me nuts. At the end of the day we are all just the IT department to our end users. They really do not care who had the good idea or floated the bad code. We are all on the same team.

If dbas and devs can work together as an integrated development team everyone does better. Those that cannot move beyond ego and finger pointing deserve the environments they love to complain about.
http://www.librisibyllini.com wnylibrarian

Vendor database design. It’s like a Bills/Lions game plan. Sigh.
http://www.trademe.co.nz Database Dave

Funny but true. We’re lucky in that we (the database team) are involved in all aspects from project consulting and architecture oversight, through to getting our hands dirty and cutting the code, and everything in between. It makes it difficult to become a guru in 1 field, but even in this environment people naturally develop different areas of strength, so we complement each other well.
http://www.johnsansom.com John Sansom

At our shop we have Application Programmers who work alongside SQL Database Developers. All of our DB Developers have previous DBA experience.

The DB Developers work closely with the Production DBA’s to collaborate on architecture and design decisions. The DB Developers specialise is T-SQL code and query tuning but have a good general understanding of SQL Server technology features, such as Replication for example. The Production DBA’s can provide additional “expert” knowledge in areas such as replication, performance tuning (not the same as query tuning) and in depth knowledge of the database engine internals overall.

It is the norm for Production DBA’s and DB Devs to work alongside one another regularly on projects and it is this synergy of expertise that we have found to produce the best results.

As is often the case there is much crossover in terms of knowledge between the Prod DBA and DB Dev but the two roles are indeed functionally different from one another, at least in our shop. It is this difference that permits the “expertise” of each role to focus in slightly different directions, resulting in superior quality deliverables when the roles collaborate on projects.