OK, I’m a DBA down this week because one of my guys ‘resigned’… but I’m making time to blog because honestly I need a short break this morning.
I’d like to talk about database science today and how it’s better than throwing yourself in the middle of application knowledge.
For starters, concentrating on the DB is a skill you can carry over to the next place you go. It’s highly doubtful that you’ll be supporting the same apps at your new gig. So it really shouldn’t matter to you whether the app counts warts on a giant’s butt or processes orders for fake vomit. A DB is a DB.
At no time has that rung true more than at my current gig. And that’s one thing that the DBA I just lost couldn’t come to grips with. He wanted to have his apps that he supported and nothing else. He thought that you had to know the app team and the product intimately in order to support it well, and that’s just not the case. And in fact, I honestly believe it can hurt you. It doesn’t have to, but it can. If you get too close to an app you start to make assumptions about performance and usage and you stop relying on numbers. And you should always investigate an issue before applying a known fix. Even doctors in the heart of Africa in the middle of a TB outbreak, still run the test when someone comes in with TB symptoms. Because it might not be TB and they could really hurt the patient if they give them the wrong medicine. Of course, he could have said, I’m in the middle of TB country and everyone around me has TB, so this guy must also have it. But he doesn’t because he knows to rely on the numbers, not what he’s become familiar with. So yeah, you can get familiar with the problems an app has and it can speed you to a solution, but never stop confirming it before you do anything.
So this has helped today in another way. By not getting too close to my apps I’m able to step right in and pick up where he left off. I don’t have to know the nature of the app or how the app team likes to do things to setup a good backup routine. I don’t have to know what the app does to diagnose a blocked spid, etc. It’s all just DB work.
I don’t know why some people think that you have to be intimate with an app in order to support it. There can be some mild benefit sometimes, but in general I find it clouds my thinking.
I can see the point you are making. However, in small businesses a DBA can also be the application developer. I definitely agree with you; a DBA you should always trust the numbers and not the application. Developers don’t always do the right thing when it comes to database interactions.
I have really mixed feelings about this, because I am in a role where I am having to both the development and the DBA work. I have seen plenty of times where knowing the app inside and out has helped me figure out the source of a problem faster than I otherwise could, but I have also had a lot of times where if I had just depended on my knowledge of the app, I would have gone in completely the wrong direction.
I would definitely say that the world would be a better place if the application developers had to do some time acting as the dba for their apps. At very least, it would make them think twice before they write code that doesn’t scale and hopefully let the DBAs know about the potential problem.