What are the arguments against or for putting application logic in the database layer? NOTE The audience of programmers.se and dba.se is different, and will have different viewpoints, so in this instance I think it's valid to duplicate What are the arguments against or for putting application logic in the database layer? on programmers.se.

I couldn't find discussion on dba on this already, and the original post says it all, so:


  Most software developers want to keep
  application logic in the application
  layer, and it probably feels natural
  for us to keep it here. Database
  developers seem to want to put
  application logic in the database
  layer, as triggers and stored
  procedures.
  
  Personally I would prefer to keep as
  much as possible in the application
  layer to make it easier to debug and
  keep the responsibilities of the
  layers separate.
  
  What are your thoughts on this, and
  what should or should not be ok to
  implement in the database layer?


N.B. I'm not the OP for that question, but left the original wording intact.
Assorted thoughts...

Your database code will outlive your application client technology. 
Think of ADO.NET -> Linq -> EF as well as assorted ORMs. Whereas you can still run SQL Server 2000 code from last millenium against all of the above client technologies. 

You also have the multiple client issue: I have .net, java and Excel. That's 3 sets of application logic.

"Business logic" shouldn't be confused with "data integrity logic". If you do have clients starting transactions and doing assorted checks, that's a lot of db calls and a long transaction.

Application logic doesn't scale for high data volumes. We have 50k rows per second using stored procs. A sister team using Hibernate can't get one per second