• hoekma (1/9/2012)


    Ok, I have to be the first one to throw a monkey wrench into the conversation. For full disclosure, I'm not a fulltime DBA. I work in TSQL quite a bit, but also do a lot of work in other application tiers (business logic, ui).

    Don't you think sometimes when getting into one of these situations it's time to step back and decide whether you are using a the wrong tool? (like a hammer when you need a screwdriver). Sometimes when things are this hard it is an indication that maybe the task should be moved to a different application tier. Solving the problem in the wrong place (not saying that's always the case or necessarily the programming case that started this discuss) just for the sake of not letting the computer win may just make the app harder to maintain over time.

    Hey, monkey wrench one, that's all part of solving the problem - working out the optimal refactoring, even if you do not actually implement it there and then. If it's feasible you can so do at the time, otherwise you make a mental note and say 'Should we need to work on this, or if we need to do X or Y, then we need to move this to a different tier.'

    In fact as a general observation if I get an intractable problem that is hackily circumvented (don't deny you do this folks!) in the interest of other activity, I'll mentally make a note. If it nags irritatingly then next available moment I'll get stuck in. If I've thankfully forgotten about it, well, then I have forgotten about it.