<p>RDBMS packages today offer a tremendous amount of functionality beyond standard data storage and retrieval.  SQL Server for example can send emails, expose web service methods, and execute CLR code amongst other capabilities.  However, I have always tried to limit the amount of processing my database server does to just data storage and retrieval as much as possible, for the following reasons:</p>

<ul>
<li>A database server is harder to scale than web servers</li>
<li>In a lot of projects I've worked on, the DB server is a lot busier than the web servers, and thus has less spare capacity</li>
<li>It potentially exposes your database server to a security attack (web services for example)</li>
</ul>

<p>My question is, how do you decide how much functionality or code should be implemented directly on your database server versus other servers in your architecture?  What recommendations do you have for people starting new projects?</p>

The vendors have one set of best practices.  You, however, voice concerns with that.
Years ago I supported a
Major Software Product
. Major.
They said "The database is relational storage.  Nothing more."  Every user conference people would ask about stored procedure, triggers, and all that malarkey.
Their architect was firm.  As soon as you get away from plain-old-SQL, you've got a support and maintenance nightmare.  They did object-relational mapping from the DB into their product, and everything else was in their product.
This scales well.  Multiple application servers can easily share a single database server.