As long as the models are eating celery and diet pills, the database will be weak as a kitten, which means the system as a whole will be slow and weak. Put them on a heavy diet of procedures, triggers, views, rules, etc., and the system will have awesome power that only comes with fat model thundertheighs.

Features, flexibility, and performance are just some of the advantages. The most important is probably improved data integrity. Many apps rely solely on their own data scrubbing to prevent bad data from making it into the tables, but constraints in the database itself the vital inner citadel.

Another big one is reliability. When someone reinvents the wheel (e.g. transaction save points or cascaded deletes) in the application instead of using those features in the database, they are unlikely to put as much development effort as the database vendor did. That means they will be bitten by esoteric bugs and corner cases that only come out after long testing periods or over a wide number of production deployments. Using those heavily tested features of the database improves reliability and reduces bugs.

But the most important value of databasism to me, personally, is clarity. Moving thousands of lines of code out of the application and into the database where it belongs has a tremendous simplifying effect on the application source. It can make something that was impossibly complicated down to just managable. Moving data-related stuff to the database improves readability, simplicity, and clarity.

The other side has advantages too. Using powerful database features is like a towering redwood that put its roots down deep. It's very hard to just up and leave one database program for another. On the other hand, reinventing the wheel in your application is like weeds. They have no strong roots, so you can pull them up easily and spread them anywhere.

Another advantage of the skinny database model is the fun of reinventing the wheel. The design and implementation phase of building your own database features is super fun. Who doesn't enjoy building cursors, compound data expansion, transaction processing, or other database features that commonly get implemented at the app level? Of course, the bug fixing phase does not result in much enjoyment.

Using the existing and proven solution of the database itself is the boring and superior option.

Another gig I did was for a large bank. There our group had no direct access to the (wholesale) customer database whatsoever. If we needed a new way to access data (select, insert, modify, whatever), we had to put in a request to the database development group, who'd supply us with (compiled) Java classes giving us the required access. Perhaps not so good for speed of development for one particular group of programmers, but if you have thousands of developers on hundreds of widely different projects scattered over dozens of locations all over the globe, controlling access to an extremely important and valuable database is important. And it makes auditors happier.

In my current gig, SQL and Perl code freely mixes. There are a lot of database classes, giving some abstraction, but that doesn't mean many programmers (including myself) don't mix SQL and Perl on a regular basis. For the current gig, being able to rapidly release new features is more important than writing beautiful abstraction layers. All code stays in house, and we have a small set of developers.

I cannot say what the best method is. Different business models and development environments lead to different solutions. I do think it's a mistake to think there's a "one solution fits all".

Our work flow was that I coded stuff in Perl, and when I had trouble writing a routine that didn't violate the tightly formulated constraints, I asked him to write me stored procedure to the stuff in the DB. Likewise when I needed a non-trivial join he came up with a stored procedure or a view.

It worked pretty well that way, IMHO. And I can recommend this working style, because it combines laziness on your side with re-usability on the database side.

If I can influence the decision it's stored procedures for everything and no ad-hoc SQL ever. Not even for selects.

This way I know what queries are run on my database, can do static analysis, generate and search through the execution plans without slowing down the system with tracing and running the risk of missing a vital query that runs only occasionally, make changes to the layout and hide them from the application(s), ensure the data consistency and business rules, ...

I've been pretty anal about this in my main past project and I do believe it paid off. Stored procedures and generated code.

But I can't really think of a good reason except for extreme performance demands to implement application logic in the DB, at least until someone embeds Perl, or something like it in a database, along with a reasonable interface. Situations requiring complex database operations and near realtime performance a the same time are pretty rare.

Application logic and business rules are not the same thing. Business rules would need to be enforced on the data irrespective of the application accessing it. And as for Perl in the database, may I introduce you to PLPerl.

I may be biased, I am a DBA first and programmer second, my preferred 'ORM' would be using stored procedures in the database when executing object methods, like DBIx-ProcedureCall