[TheTimeOfMan]

Hmmm - a portion of our business is rescuing businesses that have all their logic written in sprocs.

After several hundred no one can manage them. The same functionality gets repeatedly created, and the spaghetti multiplies.

Eventually the logic breaks, the app shuts down, the company shuts down, and we get a panic call promising us whatever amount of money we want. :-)

With a strict set of protocols and meticulous documentation stored procedures can be managed. But I advise clients to not use them except for special cases that might have critical speed or security requirements. Both of which have mostly gone away over the last few years.

[Mr. Jeeves]

Stored procedures should only break in the event of database table or structure changes - with a well-designed relational database those kinds of things should be rare occurrences. But it depends on the application - mine was finance and data structures didn't change much, if ever. They were largely used to drive reporting - all the data was there, so if a report needed to be changed or retired usually only one stored procedure was affected.

I did all the work myself, so it was easy to keep control. In a larger, team environment there are certainly reasons to compartmentalize the business logic differently - not least so that each little Indian H1B has a gig in perpetuity. :)