Am I Old-Fashioned?

  • We had similar problems finding the CPR (cut, paste, replace) code liberally sprinkled in some of our apps.  It was a bit time consuming and certainly required some regression testing, but we got back to the proc route.  We also realized that some of the Hibernate (HQL) scripts that were squirreled away weren't "optimized" for decent performance and rewrote those as sprocs.

    I don't know about the rest of you, but I've found that it's a "pay me now or pay me later" world... to get the type of performance we needed, we had to strip the database functionality out of the presentation layer and put it back in the database layer.  When we were done, things worked very well as opposed to the way they had been working even for the necessarily RBAR areas.  The side benefit realized is that it's a lot easier to develop "similar" code because of the code reuse we now enjoy with sprocs.

    I think the real key is simply to stop and think as to what should be done in each layer of an app... for example, formatting of data should not be done by the database, it should be done in the app code... calculating a thousand sub-totals from 10 million rows of data should not be done in the app code, it should be done in the database just so that, if for no other reason, you don't clog the "pipe" with the task of passing 10 million rows to the app.

    And, as some have already pointed out, people leaving the company will leave a knowledge gap... unless you properly document the code IN the code.

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

  • As another dba/developer I agree that stored procs are the way to go. Our apps are all asp or asp.net web based and database access is is now limited to a sql role and only given 'execute stored procedure' access. No datareader or data writer, no views no table read/writes just execute permissions on stored procedures. There's old software around which contains sql statements and the move to 2005 is the chance to tighten up on this by limiting the permissions and then creating stored procs to fix the breaks.

    Reports? well SQL Server 2005 Reporting services uses stored procedures beautifully. Another good reason to throw away the struggle with Crystal 8!!

  • Unfortunately I ca only go right now on what I read and not able to test the items I read as I don't have anywhere I can run RoR right now.

  • Don't know. Crystal 8 never gave me any issues trying to access stored procedures. I still have the code for passing in parameters and all currently in production with 8, although for cost reason we are dropping support early next year.

Viewing 4 posts - 31 through 33 (of 33 total)

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