It's funny, I was talking to a friend of mine and he said just the opposite, and suggested the design of Myspace as a counterexample. Everything on there is database-driven -- all the text, images, etc. The rationale is that it takes more time to reparse a flat file and insert the dynamic content than to keep the parts in separate fields in a table and pull them out at page-fetch time, and the load balancing could be done transparently because the database server connections are all happening behind the scenes.

It makes sense for a half a second until you consider that the overhead of running a database server in the first place is probably greater than any of the IO/processing time required to cut a file into several pieces, and sites that actually see enough visitors to make it worthwhile to run two servers per page view are atypical. He pointed out that, since the DB is "in memory" it's quicker to pull a record out of it... but then again, the file inode cache would be in memory as well. So yeah, I'm beginning to doubt the usefulness of running a database at all, besides for statistical purposes and (as you mentioned earlier) to simplify the code -- but if you're trying to write portable code that can run on more than just MySQL, your code is probably not even going to be any simpler, either.