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.
Best Answer
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