Logics: SQL or Code
One of the common pattern I found during my enterprise application development last year was moving the bulk of the logic to the persistence layer using SQL. Thankfully, we're a .NET shop so I wrote T-SQL mostly. But the question then: does 3-layer separation architecture really fits enterprise scenario?
Before answering the question, I would like to give some perspective on why logic was moved to database layer.
The first encounter was performance problem. The logic involved a huge data set (not System.Data.Dataset object), do complex operation on it, and return a set of data back as an output. In this scenario, putting the logic in the code will not make much sense, because obviously we will lose performance gains from large data set operation optimization you're buying from the database server vendor. If you're not using this DB feature, might as well convert your persistence layer into XML file.
The second encounter was logic protection. The client defined two separate teams, in house developers doing SQL, consultants (that's me) doing front end. The SQL will contain sensitive logic and will not be accessible from outside the server, in other words, I can only execute a SP but not open or modify it. In this scenario, putting the logic in the SQL will guarantee code security, controllable by ACL on the server. This is safe, unless someone hacked into the server, of course.
Now in both scenario, it's perfectly okay to place your logic in the persistence layer, or should I say it "persistence-logic layer". Just as UI layer may have additional UI-logic layer, so does this.
To give a balanced viewpoint, I do use 3-layer architecture. I believe that persistence layer should provide only basic CRUD operations (get, add, update, delete). These operations will then be orchestrated by the business logic layer. The problem is, for some scenario, the orchestration was very complex, that the benefit of having clear division of responsibility in terms of small functions outweighs the performance hit it cause. When it hit this stage, only then we can move the logic closer to the persistence layer.
So the answer to the question at the beginning of the post is: it fits, up to a certain extent. These patterns are for reference purposes only, and does not always mean that you have to follow it to the letter. Be flexible, and pick the best solution for any problem.