I love it when someone challenges an established belief of mine and I realize that I don't know precisely why I believe in my little nugget of wisdom. 

I came to trust a law that states: "Don't put your business logic in the database."  Our DBA, who is in charge of our project for high level administrative reasons, wants to move more and more of our system's business logic out of the Business Logic Layer and into the Oracle database.

Conceding that it is often necessary to move some data processing tasks to the database for higher performance I argued against this approach in general on grounds of it being difficult to orchestrate enterprise level tasks from inside a stored procedure.  DBA person countered that "Oracle has all that Service Oriented Architecture stuff in it."  I looked and yes, it does seem to have a lot of convenient new stuff in it such as support for .Net and Java stored procedures in Oracle 10g and SQL Server 2005 also supports .Net stored procedures. 

With this in mind it is now possible to capitalize on all the conceptual and physical benefits of object oriented languages from within the database. You can now encapsulate, inherit, and polymorphize in your database code, you can version control it and you can author it from a modern feature filled IDE.  You can use OO software design patterns and hook up web services and do close to most things you could do in a typical .Net Business Logic Layer component yet,  I am still hesitant to burn my puritanical cassock and take up the heathen scepter of a database-centric architecture.

In opposition, with your business logic now in the database you can't set up your BLL component as a remote object and scale it onto another machine.  You are bound to the database server machine for processing of business logic and data manipulation and storage.  Your database server may now be more vulnerable to bugs.  There will now be more going on in the database than the DBA is familiar with managing and good DBAs are thin on the ground as it is.

What about portability?  With the business logic in the database you can't port your application to another RDBMS; you would have to do a rewrite unless there is some massive move to standardization which there is not.

Is there anybody out there who has worked over this issue before?

Please comment with your input from either side of this debate.