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.
This Post Has 2 Comments
Troy Blake
Senior IS Manager at Logan’s Roadhouse, Inc.
I wrote about this earlier this month on my blog, “Do You Even Need A Database Administrator?” (https://wp.me/p49End-nH) and what I believe is that a DBA is an important part of your database management process. A company spends a lot of time and puts a great deal of effort into collecting the data that is important to that company, but sometimes doesn’t want to spend the money to protect that data, and make that data available to reporting processes in a reliable way, and make sure the data is protected.
These decisions are often made in an effort to save money, and there is some reason to believe that a company will save some money in the short term. The issue is the required cleanup in the long term, or the extreme cost if there is an urgent issue that requires elevated database administrator level skills and they have to scramble to find one or more qualified consultants.
I agree that keeping your skills updated will reduce how likely you are to lose your DBA job, but if it is all about saving money, jobs skills will not save your job at a company cutting head count to save dollars.
Thanks for sharing, Troy.