Longish. see Summary at bottom.
A RDBMS stands for relational database management system. It's a system to manage a relational data base. The data is stored there. The data. It doesn't say business logic.
What does business logic mean, really? To me, it's description of business processes in logical terms.
Processes are those business activities that occur regularly, enough that they are no longer ad hoc. These are different for every business.
Let me put my business cap on and explain what business means here. To some, this may come as a surprise.
Business is the sum of the activities performed to achieve the creation of value, and more specifically value that can be traded. This could mean making combine harvesters, tuna sandwiches, or providing banking services. In most of the countries of the world, even those in non-capitalistic systems, people like to get the most value for their money, and therefore there is competition between different providers of these valued goods and services. The competition generally hinges on price, quality, and availability.
Quick detour: You need 40 million rivets in 2 days, you're not going to order from some guy on the internet with a paypal account, no matter how much cheaper his price is than that of your normal vendor.
As you can imagine, the processes involved in making this "value" mostly live in the executive heads. Some of that is put on paper and used as company policies and procedures. Some of that lives in the heads of corporate counsel. A lot of that lives in the head of the people running the divisions, departments, teams, and those running the machines, the cash registers, the ovens, the trucks. A small subset of that ever makes it down on the business requirements for software, and an even smaller subset of that is accurate by the time it's implemented in computer systems.
In the end, the business logic that you see in code is not that which runs a business, it is that which runs the application for the business. The actual brains inside actual people hold the actual business processes, and they have no problem understanding that the process in their brain is more accurate than the process in the computer. As an aside, you could probably not run the business if all you had were the policies and procedures of most corporations. Very often these are grossly inaccurate, despite herculean efforts.
So in the end, it is the application logic that is coded into the software. And people want to put that into the database, because database management system vendors have made grandiose claims.
I say no. I say application logic stays inside the application. The data goes in the database, in a very normalized way, and then gets ETL'd to the datawarehouse for reporting and drilling and rolluping and pivoting and cubing.
I also say that the data outlives the application, so the data normalization effort should not be application specific, and not even business-specific, but rather should be business-general. Do you store state codes? You should use INCITS 38:2009 (http://www.census.gov/geo/www/ansi/statetables.html) because that's portable across businesses. This also makes it easier for multiple applications to manipulate the data.
If you treat the database as part of the code of the application, from the tables layout to the triggers, stored procedures, and data formats, you're essentially using the enterprise database as a glorified BerkleyDB, which is a glorified flat files structure, which is really just persisted lists. This is essentially what NoSQL is doing: going back to the roots, but doing it in a multi-process, persisted, failure-tolerant manner.
No, you need to treat the data base as a common repository of data for multiple applications, both current and future. Now we come to the crux of my argument. Business processes change with the vagaries of the market, politics, and fashion. Very often they change faster than what coders can manage with computer-science-grade languages (Java, C#, C++ etc) and end up being written in VBA in excel spreadsheets in the accounting or marketing department. (And only if it can't be expressed in fancy vlookups...)
The data doesn't change much if it's well organized. The business logic changes very fast. By putting business logic in the database, you make the database less valuable, because it will become obsolete and inaccurate sooner.
Data must outlive the application because business processes live in the application and business processes change much more often. Including business logic in the database is bad for its longevity and overall value.
I've done my share of dba-ing and I've read the answers at dba.se but in all honesty what they're talking about is data-integrity issues and performance issues. I completely agree that people who touch corporate data should know what they're doing, whether dba or programmer or SAS senior analyst with read/write access.
I also noted that they recommend coders know SQL. I agree. It's a computer programming language, so I don't see why computer programmers would not want to know it.
Later on, after thinking about it
I think the middle ground is to make an API, and have that API manage the data flow to and fro. If you can't allow apps to connect directly to tables, at least you can make the access mechanism be in modern languages.