Do a Google search for “the DBA” and one of the top auto-fill results will be “…is dead.” In recent months there has been a flurry of articles on the idea. If enough people blog about a subject, does that make it true?
We don’t think so.
This is the digital age and data is the coin of the realm. “Apps” are as much a part of our lives as the TV, the microwave, and the ATM, and someone needs to manage, secure, and optimize the data behind those apps. If that person is not an “expert” (loosely defined), what assurances do you have that systems won’t go south?
Consider this insight from a visitor on SQLServerCentral:
As long as there are developers (without DBA mind-set) creating databases out there, and I see it almost every day, there will be the need for DBAs.
I fill both roles but managers within the companies that I’ve worked for prefer to hand the whole job to a “lead” SQL developer. This normally ends up with a single database file with no backup strategy, missing referential integrity, throw everything in the dbo schema and very little consideration for security.
A recent case saw me presenting an architecture that included multiple schemas to a manager who immediately replied that it would be too complicated to manage security. When I mentioned database roles he stated that it would be too complicated for the developers to get their heads around.
Some time later I was called in to clean up the integrity and security of the design they made up themselves and it cost more than if they’d used a more “proper” architecture. I ended up having to redesign their database to my original design and creating views as an “interface”.
The more these “DBA-less” scenarios are touted, the more managers will think they don’t need DBAs when, actually, we’re the first person they need.
Granted, he’s making a case for DBAs because he is one. But his argument is hard to refute.
In other words, if you want a database done right—or at the very least, fix it when it breaks—it’s probably best to have a DBA handle it. A company’s proprietary data is usually extremely valuable, and protecting that value, and all the investment it represents, is essential.
Do you need an on-staff DBA?
So does that mean you should hire a DBA? Not necessarily. It may make more sense to outsource DBA functions to a third party—as much or as little help as you need, when you need it. There’s something to be said for flexibility. You just have to consider the trade-offs and make the choice that’s right for your organization.
And if anything should go wrong and you don’t know where to turn, there’s always SSG. You want us on that wall. You need us on that wall.