• David.Poole (8/31/2016)


    I strongly suspect that developer antipathy to stored procedures is rooted in organisation structure rather than pure technical arguments.

    • Stored procs being seen as a DBA thing taking control and flexibility away from the developers.
    • ORMs being seen as a developer thing taking control and flexibility away from DBAs.

    Then you have the mis-education piece where a surviving brain donor with a big mouth has heard the argument for their camp and the argument against the alternative. They then preach a flawed gospel VERY loudly and sadly convincingly.

    The reality is that an open-minded multi-skilled team will quickly determine that some database interaction is ORM friendly where as other stuff is not.

    They will gather that calling getGoldCustomers is preferable to a horrendous piece of C#/Java/<insert latest fashionable language here>.

    An ORM is code that writes code, just as HIVE is SQL that writes map-reduce code in Java.

    ORMs can call stored procs anyway so it is the genius of AND rather than the tyranny of OR.

    Maybe you have complicated security requirements. Data security may be easiest to enact with security groups/database roles. Occasionally a more complicated infrastructure based approach may be more desirable.

    All professions have tools that in the wrong hands can be dangerous. The problem is the wrong hands, not the tool.

    There aren't enough agreement points in the world that I could give you on this. Lots of people are excited about the notion of "DevOps" but few are willing to give up their ivory towers to make it work the way it should have always worked even before the newest buzz-word of "DevOps".

    The key is and always has been in the code itself. What works best for a given situation is what every company and the individual teams in a company should strive for.

    I also wish that people on both sides of the fence would realize two things... 1) they don't know everything about all the tools and so they're going to gravitate towards what they know and that could actually be a mistake so they need to work with others that do know and 2) when all you're trying to do is drive nails, you actually should use a hammer and it needs to be the right kind of hammer. I'm always thrilled when someone invents a new sledge hammer to drive thumb tacks and then a world of minions insist that's the best thing to do. I also love it when they develop new and improved two headed hammers that are guaranteed to leave a nasty mark in the surface because they're only trying to drive one nail. Then there are those that don't even know what hammer is and insist on using a new and improved saws-all to drive the thumb tacks.

    The good part of all that is that there will always be performance and resource issues to solve and the old hammers and skills to use them properly will never fall out of demand because of that. 😀

    --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)