I build webapps for a living and I never put application files (code, templates, config, etc) in a servable directory. In fact, since most of my apps have to be completely dynamic, I have very little that is servable outside the following categories:

• images
• static PDFs (for help docs, privacy policy, and the like)
• stub CGI scripts to get CGI::Application up and running

Everything else, and I mean EVERYTHING else, is somewhere else. Often, different places. My perl modules are in /usr/local/lib. My templates and config files are in /apps/<APP>, and this includes my httpd.conf. /usr/local/apache2/conf/httpd.conf solely contains an Include directive. (I do it this way because I generally have 2-5 apps running on a given group of round-robin servers. My dev assignments don't often match my production assignments.)

I want to need to have root permissions to upgrade stuff on the production box. I want to know that only specific people can touch it, and every one of them (except me) doesn't. But, I'm also the admin for every bit of web prescence my employer has, so being paranoid is good job security. :-)

Oh - databases are for just that - data. Not only should templates not live in a database, but you shouldn't have any triggers, procedures, or the like that are application-specific, for several reasons.

• You sure your database is going to be used for that application and only that application?
• You sure you trust your DBA to be a programmer?
• You sure you trust your programmer to be a DBA?
• You sure you trust Oracle's patches? (Skip 9.2.0.3 - Oracle has said "Sorry bout your luck - hope you can save your data.")

If everything but your data is outside your database, you have a chance of changing vendors, especially to like PostgreSQL or MySQL. But, if you tie yourself to Sybase or MS SQL or Oracle by using their flavor of triggers, PL/SQL, etc ... your boss might not like to hear "I need another $XXX cause they're discontinuing our license." when there's a perfectly good open-source option.

Now, I'm not discounting triggers, procedures, or the like. But, IMHO, you should only use them for data-specific purposes. For example, using a trigger to do automatic history on a given table - that's a data question and properly belongs in the database. Using a trigger to make sure that X gets populated when Y does because it's easier than fixing the 9 places you populate Y ... that's not so good.