Stored procs, or SQL code located in a module off to the side have the exact same maintenance issues and the same potential coupling problems with the rest of the code.

Using stored procedures can make the code more modular, and more efficient, in particular for RDBMS systems where multi-version concurrency and long running transactions aren't handled well. In that case the stored procs allow for well-defined, short lived transactions that can be (mostly) independent of one another, avoiding most deadlock and similar problems.

It is my considered opinion (based on 20+ years of experience :-) that they are good for you.

Now triggers are a different story - they are a form of stored procedure, but their behavior and nesting can make the system's schema be rather difficult to understand (lots of nested rules buried in the triggers, sometimes).

Michael, Sybase (and somtimes Oracle) DBA.