I like the database + filesystem approach, mostly because it plays to the strengths of the different vehicles. Apache + browser is a very mature system for delivering slowly-changing information efficiently, so i try and use it for that. It isn't optimal for volatile data - just as handmade html isn't - but here the database output is ideal, so I write the world's 23,902,371st content management system.

I think pictures fall into the first category. They don't change much, they're never edited in situ, they're not analysable or indexable and they need no formatting that they don't already have.

In this context using the filesystem is a natural part of the http sequence: the page generated from the database triggers the subsequent requests for images. To have those requests go back to the database seems unnecessary when you've got such a good image delivery mechanism sitting there already. You don't even need to manage a folder structure: dump everything in one place and use the database metadata to update and delete it.

An analogy: consider what happens if you succumb to a broadband evangelist and add video clips to the player profiles. As well as delivering proper image headers, your database system will have to be able to hold and stream the bulky new clips. It's possible, but rather redundant when there are perfectly good mechanisms for streaming it already and they only need to be told where it is.

I think this is a case where two heads are actually simpler than one, given their different strengths. The system you describe is structurally more elegant but practically less efficient.