After reading this post (business logic database or application layer) I still don't have the sufficient reasons to fight the "business logic in database" topic.
In my current work, there is a lot of db transaction (actually) and all that crappy code is hard to maintain, a lot of duplication in the stored procedures, so if you want change a value in a table for a bit, you will need to find all of those procedures and change them to what you want. Same happens if you need to change a little bit a table design.
All the current developers know SQL very well, but they still being not experts in any DATABASE as a engine(8 devs).
Currently we are planning to migrate the entire core to a new version (including database design). And I need some examples of:
App Language: Java
Database: Oracle11g
The application will have Services, served as HTTP pages and as WebServices.
Crappy code is indeed hard to maintain. That is the nature of crappy code - not where it is located. Moving to a "crappy code in the front end" solution is, well, not really a solution.
And if you think database structural changes won't affect business logic coded in the front end... ummm - logic dictates differently.
I think some things are well handled in the front end, and some things are better handled in the back end. And I think that a proper PL/SQL API design that operates at a business object level can mitigate structural change problems by isolating them from the other layers.
But if there is any thought to supporting other DBs, then this is also a problematic idea as not every DB supports the same constructs.
As to where business logic belongs - that may depend entirely on your application and, indeed, for performance reasons you may find it advantageous to have some aspects of it in multiple layers. That, of course, can cause maintenence issues but this all becomes part of the trade-offs neccessary to deliver a project or product.
But there sure ain't one strict universal answer.