Results 1 to 7 of 7
  1. #1
    Join Date
    Apr 2002
    Location
    Toronto, Canada
    Posts
    20,002

    Unanswered: stored procs are BAD!! BAD, i tell you!!!

    almost choked when i read the following recent post on The Daily WTF the other day --

    Logical Tiers? That Makes No Sense!

    i don't think i can do justice to how utterly stupid that stored procedure is

    read the comments and have a laugh

    one of the points made was that stored procedures are bad

    this twigged something in my memory, so i dug around in my bookmarks, and sure enough, here's another decent discussion about stored procs --

    Stored procedures are bad, m'kay?

    enjoy!
    rudy.ca | @rudydotca
    Buy my SitePoint book: Simply SQL

  2. #2
    Join Date
    Jun 2003
    Location
    Ohio
    Posts
    12,592
    Provided Answers: 1
    Why in the world did you point me to that crap?

    Jeez, I though things got bad sometimes on this forum! I couldn't find one poster on that site that didn't have his head up his butt in one way or another...

    What they all seem to be missing is the fact that populating drop-down boxes isn't even business logic. It's pure presentation layer! So how can they use that to argue against coding business logic into the database layer?
    If it's not practically useful, then it's practically useless.

    blindman
    www.chess.com: "sqlblindman"
    www.LobsterShot.blogspot.com

  3. #3
    Join Date
    Apr 2002
    Location
    Toronto, Canada
    Posts
    20,002
    the posters who simply agreed that coding the html into the stored proc was wrong were anatomically okay

    rudy.ca | @rudydotca
    Buy my SitePoint book: Simply SQL

  4. #4
    Join Date
    Feb 2004
    Location
    In front of the computer
    Posts
    15,579
    Provided Answers: 54
    Quote Originally Posted by r937
    the posters who simply agreed that coding the html into the stored proc was wrong were anatomically okay

    You mean that you don't build web apps by doing a simple SELECT ... FOR XML from within an otherwise empty ASP frame ?!?!

    -PatP

  5. #5
    Join Date
    Jul 2003
    Location
    San Antonio, TX
    Posts
    3,662
    Interesting interpretation, Mr. Lindman, except your definition of presentation layer is a little bit off (check this site for explanation) What I've seen in this regard was that the choices made to use or not to use procedures for specific app functions, were not based on deep knowledge and understanding of pros and cons (are there any?), but rather on lack of such. So, all their blabbering is just a way to get to the truth, the one that many of us here have already found.
    "The data in a record depends on the Key to the record, the Whole Key, and
    nothing but the Key, so help me Codd."

  6. #6
    Join Date
    Jun 2003
    Location
    Ohio
    Posts
    12,592
    Provided Answers: 1
    I'd be in favor of splitting the term "Business rules" into at two areas. "Presentation rules", and "data rules". Rules that apply to data, and need to be constant across all applications using the data, should (if possible and practical) be coded in the data layer (stored procs, etc). Those that deal with interaction with the user, or which may be allowed to vary between interfaces should be coded in the presentation layer.

    By this standard, the application should have used a stored proc to generate the list, and the presentation layer should have formatted it as HTML.
    If it's not practically useful, then it's practically useless.

    blindman
    www.chess.com: "sqlblindman"
    www.LobsterShot.blogspot.com

  7. #7
    Join Date
    Jul 2003
    Location
    San Antonio, TX
    Posts
    3,662
    I agree with "Business rules", but "Presentation rules"??? It's nothing but a user interface design, that should follow the internally accepted standards (serious shops have standards, not so serious - should follow standards established by serious shops), that in turn should adhere to thoroughly conducted systems analysis that should include management expectations as well as availability of adequate user resources. Too many times I've seen a seemingly clumsy structure of a form, that followed the same UI concepts throughout the app, and received the highest user acceptance and consequently was the determining factor in software selection.
    "The data in a record depends on the Key to the record, the Whole Key, and
    nothing but the Key, so help me Codd."

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •