Many 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.
It’s the same way you teach your kids lessons when you want to drive a point home to them. Just last week we were at the store with our daughter. She’s been told to not set her phone down in public where it’s easy to get lost, stolen, or just forgotten. She set her phone down on a shelf to look at something, and about 5 seconds later we picked it up and put it in our pocket. She noticed it missing very soon after that, but being 10 she couldn’t decide how long it had been gone. So she want all around the store looking for it. This was a lesson she needed to learn, and it’s best if it’s at our hands. No long-term harm was done, and we got to teach a lesson.
It’s really the same thing when you do it in SQL. There are lessons you can teach people that will help things along, and as long as you’re not doing it in a hospital database (or other equally important system) where you could kill someone, you could be doing more good than harm.
Now don’t get me wrong. I’ve never personally taken place in such activities (cough cough), but I’ve seen it plenty of times and I’ve even seen it requested by management plenty of times. So why would management request something like this? Maybe the manager of your division wants to prove something to the manager of another division. Maybe your manager wants to prove something to a vendor. Things like this will make management get involved in things like this.
Anyway, I’m not saying do it and I’m not saying don’t do it -- I don’t want anybody blaming me for the outcome of such actions. You need to consider your own environment and the consequences of such things for yourself. I’m merely saying these tactics exist, they happen all the time, and they can be very effective -- or so I hear.