SQL Clone
SQLServerCentral is supported by Redgate
Log in  ::  Register  ::  Not logged in

Developers vs. DBAs

By Jim Youmans,

I just read a post stating that the application is the heart of the system.  The database is just a way to store information that the application creates and manages.  Of course this was written by a developer.

Then the DBAs respond with unkind words and point out that if the database goes down, the application dies a horrible death.  On the other hand, if the application dies, there is still full access to the data and a new application can be designed to make use of it.   

I like to think that the application and the database are both part of a larger entity.  They are like the brain and the body, they have to both be healthy and working in tightly coordinated harmony if you want a robust and useful system.

If this is true, then why aren’t the DBAs and the developers working in harmony?  In my last few jobs, the developers live in one armed camp and the DBAs in another.  Both are wary of the other and both blame the other for any issues that crop up.  The developers like to say that DBA stands for Don’t Bother Asking, and thus the developers are embracing ORM’s, like the Entity Framework, to get around having to deal with the DBAs.  The DBAs point out that the developers don’t understand what it takes to keep a large database running and optimized and that the developers can’t be bothered to learn how SQL works and just rely on ORMs poorly written ad hoc queries.

Both are right, and wrong.

Many developers don’t understand SQL and consider it to be archaic.  Then want SQL to be more like the code they write in .NET. The Entity Framework gives that to them, and they are happy.  The problem is that if you don’t understand how the underlying SQL works. You can’t tell when your ORM creates an unsupportable monstrosity until it is too late.

DBAs on the other hand, don’t always understand how tedious it can be to write code based stored procedures and views.  They don’t like the fact that ORM’s tend to avoid stored procedures and use ad hoc queries.  They are frustrated that they are held responsible for how the database performs, but they can’t optimize or control the ORM created code that is causing the issues.

Is there a way to bridge the divide here and unite the two fractions?  I don’t know.  From what I have seen, the divide is growing not shrinking.  Developers ask if DBAs are really needed anymore and DBAs see more and more applications that can’t scale or be optimized.  Where will this end?  How will it end?  I guess only time will tell.

Total article views: 612 | Views in the last 30 days: 1
Related Articles

Team-based Database Development: Playing Nice With Others

Here are the slides and links to awesome resources for my presentation, “Team-based Database Develop...


The Multi-skilled Developer

Is the DBA a fading star? More likely, there is a general lack of understanding of the roles of the...


Application Developers don’t own their data

As a data guy, I always smile when application developers refer to ‘their’ data. If only it were tha...


Presenting “Understanding Execution Plans”

The PASS Application Development SIG is hosting a web cast next week on Tuesday where I’ll be pres...


Stairway to Database Source Control Level 3: Working With Others (Centralized Repository)

One of the main purposes of placing a database under source control, alongside the application code,...