1. Yes, stored procs are pre-compiled. Modern DBs also cache plans for frequently used queries. As a result, what we're now seeing is that stored procs have lost the speed advantage they used to enjoy.

2. Stored procs save repetition. Yes, this is true. So does *any* ORM, or in fact, any system in which you can create functions, libraries, etc. And they will usually be much more "discoverable" to programmers than stored procs too. Stored procs are MISERABLE to work with as a developer.

3. "In no case, should one ever feel that stored procedures are a "maintenance disaster" in a professional development environment. If one does, truly, one or more things are seriously wrong and require fixing with more training, proper tools, and education."

I have yet to see an environment where the stored procs were handled anywhere close to as well as the rest of the software code, even when professional, experienced DBAs were involved. Take the following scenario:

* Table A is made with rows X, Y, Z. X is the primary key.
* Stored proc "GetFromA" is made that accepts a value for X, and returns X, Y, and Z.
* Column W is added to Table A.
* The DBA cannot change GetFromA, because who knows if a piece of code is depending on GetFromA returning three columns? The DBA is forced to make another version of GetFromA, because ANY CHANGES AT ALL to GetFromA will potentially break applications that depend upon GetFromA.

You see the problem?

A FUNDAMENTAL rule of development is that you can't change the "signature" of functions, and there is no 100% accurate way in the world to audit who the consumers of a stored procedure are. And the columns returned by a store proc are part of its "signature" to the developer.

Now do you see the problem?

4. "The person who maintains an application, in my vast experience, has never had a problem identifying what stored procedures are being used by the app. A stored procedure is either identified in the code or it is not being used in that code."

Your experience is lacking in a lot of the circumstances and situations that I have been in. Because in environments where folks are using languages like Ruby, Python, Perl, etc. it is nearly impossible to do what you describe.

Once you get into a full boat environment where folks can access the database through more than a few bottlenecked technologies, stored procs go from bad to worse on this stuff.

J.Ja