In addition, having your templates talk to a database doesn't violate MVC, in and of itself.

Yes it does. Should one layer change, the other will have to change. You should have some conduit/api where one talks to the other, such as a function or something. And that usually does not include putting DB stuff directly in your templates... unless you can show me an example where I'm misunderstanding your meaning. :)

Let's take a real-world example that I have worked on - a site that is available in 12 languages. Obviously, what language you present in is a V-layer issue. So, when you want to specify the column names for your report, you indicate in your code (either in the template or in the script) that you want the names for column 1 .. 5 in language $lang. The template would then lookup in a front-end database what the actual strings are for those columns in that language.

I rather the second oddly enough, but not have column names tored in the database. Use a properties file for that, and internally assemble them as template variables. But you know what, in the end, the devil is in the details of the technolgoies you are using.

The reason I'm used to not putting things like, display stuff in the database, particularly column headers, if that's what you mean, is because the technology I use for populating them into HTML, is the same one i use for email/smtp and desktop applications.

But this is all religon, we can argue for days. :)