• TomThomson (4/20/2015)


    Interesting discussion.

    I think Conery's article is excellent, never mind the phrasing look at what is being said.

    It's a pity that some people seem to believe that using stored procedures for all access implies putting application logic that belongs in a higher layer in the data layer; that's such a crazy distortion of the facts that I think that anyone who believes it must be suffering from some combination of three delusions: (a) the function of stored procedures is to grab control of all the logic and not to ensure that the interface between the data layer and the software that uses it can not be manipulated in such a way as to prevent changes within the data layer that ought to be invisible to its users; (b) the mantra "no business logic in the database" means stored procedures can't be allowed to happen; and (c) data integrity is no concern of the data layer, it's the applications' business.

    I started advocating that all access to data in a shared database should be through stored procedures a very long time ago - in fact I've done it ever since I realised (a long time ago, before there was any such thing as MS SQL Server) that we weren't going to see a fully declarative relational calculus based on the functional programing paradigm replace SQL at any time in the near future. Of course some databases aren't shared, they are the private data of some individual, and there it may not (depending on the individual concerned and what he wants of his data) be appropriate to apply the rule.

    The "no business logic in the database" argument is regularly used to doom projects to failure by assigning data integrity maintenance to the front end and forbidding the use of constraints in the database "because they damage performance" (when in practise they usually improve it) and rejecting normalisation because (a) it wastes disc space (it usually saves it) and (b) it requires those nasty constraint things, so it's putting business logic into the database.

    Some of the comments I've seen here suggest to me that plenty more catastrophes may be waiting to happen because the developers and dbas who made those comments could be ensuring that it's inevitable that data access will be the "cluster-fucked echo chamber of half-assed rocket engineering and cargo cultism based on decade-old cathedralized thinking and corporate naval -gazing" mentioned by Mr Conery.

    (what naval-gazing as opposed to navel-gazing might be is beyond a landlubber like me, perhaps Jeff can tell us as submarines are somewhat naval?)

    edit:correct the English

    +a billion.

    Naval-gazing is just what you would expect whether you're in the Navy or not. The neat thing about doing it in the Navy is that there's usually enough time to pluck the observed t-shirt lint from it and save it to make a very personal pillow not likely to be useful to others. That's also a powerful metaphor for what "corporate naval-gazing" means. 😀 Really good corporate naval-gazers are also skilled at the meaningless skill of inserting a cherry in their naval, calling everyone's attention to it, and then doing some ridiculous move to shoot it across the room... lint included. 😛

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