Database Taming

  • Comments posted to this topic are about the item Database Taming

    Best wishes,
    Phil Factor

  • A month ago, a client reported a problem with how our software app (for mobile sales order entry) was exporting pricing data to some users. After an hour-long conference call between myself, my colleague and three people at the client's office, we had agreed on a new approach (devised mainly by me) that would involve changing the folder structure on the server, updating software and configuration files on the affected mobile devices, and quite a bit of testing and deployment planning. In all, it would involve hours and hours of work by many people.
    Then, I had a Kekulé moment. Late that night, after I had completed the first step (changes to the export software), just as I was dropping off to sleep, I thought of a much simpler change to the SQL query at the heart of the problem that fixed it completely without any of the other planned changes. Five minutes of work instead of many hours. It was a little embarrassing that I didn't see it at the outset, but it was one of those things that is more obvious in hindsight. (The solution was creating an additional  join between two tables that were already involved in outer joins to the main pricing table).

    In theory, theory and practice are the same. In practice, they are not.

  • I find the same.  I tell my bosses I don't single task well.  I need to have multiple things to work on.  When I only have one thing to work on, and then run into an issue, I have to keep at it, because there's nothing else to work on.  The only breaks come with the end of the work day.  When I have multiple tasks and I run into a roadblock, I switch to another task while I mull the blockage in the back of my mind.  That time away is crucial for coming up with a solution without spinning my wheels.  Stepping away from a difficult issue, when that's possible, is highly recommended.

  • It's amazing how stepping away from a problem can help you solve.  I think sometimes when we've stared at something for too long, our brains start to get into a rut.  And the more you "gun the engine", the deeper the rut gets.  Stepping away allows you to find a different route.

  • "Either you master therecalcitrant database or retire, sadly, into the dingy half-life of ITmanagement."
    Literally LOL

    Thank you Phil. you just made my day 🙂

  • I've always told people that half of my job is trying to get the technology to do what it's supposed to do!  Of course the other half is trying to figure out what people really need it to do compared to what they say they want it to do.  😉

  • This is not an SQL Server only issue, I find it to be true in most computer work. I must find the answers and solve the problems. It is me against the situation in a cage match. 
    Sometimes I win, sometimes I resign and come back after a day or two and win. 
    The important thing to remember is your time awake and working affects your ability to think straight.  You can become snow-blind (if you will) and the best case scenario is you don’t do any damage.
    You need sleep to be your best, look at all the studies that show overworked people are not just less productive but actually make more mistakes.
    Even knowing this I too, will often think I can fix it just give me five more minutes.
    I call it the Video Game “Level Up Syndrome”

  • I look at it more like the Robo-Cop movies, particularly the one where Robo_Cop is "blessed" with a thousand directives (think "best practices") to get along with humans.  In the end, he throws himself on an electric fence to purge himself of all the preconceived notions bestowed upon him by people that don't actually have a clue and get's back to the basic directives he actually started out with.  There's a parallel in programming... there are certain basic directives ("best practices") that simply must not be ignored but don't let all the other junk cloud your own abilities to think.

    And, yeah... I absolutely agree.  Walking away from a problem to take a deep breath frequently helps especially if you not foolish enough to continue trying to fix a problem that can't be fixed and needs to be rewritten instead.  Sometimes an idea will come up out of nowhere even during conversations that don't actually have anything to do with what needs to be done.  A favorite example was in the movie about Turing trying to crack Enigma.  He had the machine for it but not the clue he needed until someone totally not involved with any of it made a comment about someone ending every message with "Heil Hitler".

    Heh... and no... not a good idea to stare a lion in the eyes, proverbial lion or not because that'll just mean that you'll be able to see the lion's tongue as he rips your head from your body.  😀  Much better to "keep your head" both with a lion and when trying to solve a problem.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

Viewing 8 posts - 1 through 7 (of 7 total)

You must be logged in to reply to this topic. Login to reply