A lot of thins have been said about performance, caching, and security in this thread already, and I won't repeat those points. There are a few things that I haven't read yet in this thread, which is portability issues and rountrips.
- If you are interested in maximum portability of your application across programming languages, then stored procedures is a good idea: the more program logic you store in the database outside the app, the less you have to recode if you're moving to another framework or language. In addition, the code to call a stored procedure is much smaller than the actual raw SQL itself, so the database interface in your application code will have a smaller footprint.
- If you need the same logic in multiple applications, then stored procedures are a convenient to have a single definition of that logic that may be re-used by other applications. However, this benefit is oftn exaggerated as you could also isolate that logic in a library that you share across applications. Of course, if the applications are in different languages, then there is true benefit in stored procedures, as it is probably easier to call a procedure through your language's db interface than to link to a library written in another language.
- If you are interested in RDBMS portability, then stored procedures are likely to become one of your biggest problems. Core featres of all major and minor RDBMS-es are quite similar. The largest differrences can be found in the syntax and available built-in functionality for stored procedures.
Regarding roundtrips:
- If your have many multi-statement transactions, or in general, functions in your application that require multiple SQL statments, then performance can improve if you put those multiple statements inside a stored procedure. The reason is that calling the stored procedure (and possibly returning multiple results from it) is just a single rountrip. With raw SQL, you have (at least) one roundtrip per SQL statement.
