Database tough love
Sometimes it's necessary to exercise tough love to get your systems running well
Follow @infoworldMany of you may not know what I’m about to tell you: There’s a darker side to databases and especially to being a DBA. It’s not evil, but it’s definitely calculating and nefarious. Consider it the white hat hacking model for getting your way.
Let me outline this for you. As a DBA you spend a lot of your time giving recommendations to your user and dev communities. And let’s face it, they often don’t take your advice, and they argue against it like you’re an idiot telling them the world’s about to end. There are only a couple of ways you can handle this type of situation: You can try to convince them over time and hope you can come up with the right combination of examples that will adequately prove your point, or you can cut to the chase and produce the situation yourself.
[ Cut straight to the key news for technology development and IT management with our once-a-day summary of the top tech news. Subscribe to the InfoWorld Daily newsletter. ]
The first way is difficult and may never work. There are things I’ve been preaching at my current gig for three years, and the devs still don’t get what I’m trying to do. I’ve explained it so many times and in so many ways that I’m not even sure it’s worth it anymore. And they’re no closer to understanding than they ever were.
The second way can be quite fruitful, though. Let’s say, for example, that you’re trying to explain to your dev why he shouldn’t put insert triggers on your big processing table. Since the original lock will hold until all triggers fire, it makes perfect sense that you would only use triggers if you absolutely had to. You’ve given the dev alternatives, yet he insists on putting triggers on it anyway. Maybe next time you do index maintenance, you raise the fill factor on those tables to increase the chance that the triggers have an adverse affect. It’s nothing that probably wouldn’t show itself eventually anyway, but there’s nothing like an immediate result to teach someone a real lesson.
This tactic does a couple of things. First, it forces your dev to change his thinking because his plan has failed. Second, and more importantly, it forces him to take you seriously next time because you were so incredibly right this time. Everybody wins -- even the dev because he not only gets a system he can be proud of because it’ll perform better, but he also gains some much-needed faith in his DBA who he realizes (finally) is here to help him.
