Here is where the meeting of the minds, that is to say, the minds of Developers (DVs) and DBAs, must inevitably happen. Working with Business Logic (BL) and storing such in a database can have an impact that can either glorify or horrify its implementation.
For some RDBMS products, there exists superior libraries/tools/APIs for Business Logic and Object Infrastructures one could quickly learn and employ in their applications. For other RDBMS, no libraries/tools/APIs exist.
In the past, client server apps made the bridge into BL via Stored Procedures (SP). For products such as Oracle and SQL Server, this was done early. As open source databases such as PostgreSQL and MySQL came into being, those using them were at risk of breaking new ground with stored procedures in BL. PostgreSQL matured very quickly in this, since not only stored procedures were implemented but also the ability to craft customer languages also came along. MySQL basically stopped evolving in the world of stored procedures and came in a stripped-down form of a language with many restrictions. Thus, when it comes to BL, you are completely at the mercy of MySQL and its Stored Procedure language.
There only really remains one question: Regardless of the RDBMS, should BL resides in whole or in part in the database ?
Think of the Developer. When things go awry in an application, the debug process will have the Developer hop in and out of a database to follow data chanages that may or may not be correct intermittently. It is like coding a C++ application and calling Assembler code in the middle. You have to switch from source code, classes and structs to interrupts, registers and offsets AND BACK !!! This taking debugging to that same level.
Developers may be able to craft a high speed method of executing BL in conjunction with language configurations (compiler flags for C++, different settings for PHP/Python, etc) via business objects sitting in memory rather than in a database. Some have tried to bridge this ideology for faster runnng code into the database by writing libraries where debugging Stored Procedures and Triggers is well integrated in the Database and seemlessly useable.
Thus, the Developer is challenged to develop, debug, and maintain source code and BL in two langauges.
Now think of the DBA. The DBA wants to keep the Database lean and mean as much as possible in the realm of stored procedures. The DBA may see BL as something external to the Database. Yet, when SQL calls for the data needed for BL, the SQL needs be lean and mean.
Now, for the meeting of the minds !!!
Developer codes SP and uses iteractive methods. DBA looks at the SP. DBA determines that a single SQL statement can replace iteractive methods written by the Developer. Developer sees that the SQL statement suggested by the DBA requires calling other BL-related code or SQL that does not follow normal execution plans of the SQL statement.
In light of this, the configuration, performance tuning, and SP coding becomes a function of the depth and data-intensiveness of BL for data retrieval. The more depth and data-intensiveness the BL, the more Developers and DBA must be on the same page for the amount of data and processing power given to the Database.
The manner of data retrieval should be always involving both Developer and DBA camps. Concessions must always be made as to what coding methods and data retrieval paradigms can work together, for both speed and efficiency. If the preparation of data for source code to handle is done only one time before the code gets the data, the DBA should dictate the use of the lean and mean SQL. If the BL is something the DBA is not in tune with, the reins are then in the hands of the Developer. This is why the DBA should see himself/herself and part of the project team and not an island unto himself/herself, while the Developer must let DBA do the fine tuning of the SQL if it does warrant it.