I go under the theory that File systems are designed to be good at storing files and that Databases are designed to be good at storing data. While it is true that files are data, I think that there are plenty of attributes about files that make them different from the types of data that we normally store in databases. Files are independent entities. They have a structure of their own, they are executable on their own, they have their own metadata built in. This is not generally true of most of the snippets of data that we store in a table. We are purposefully setting up a scheme to provide metadata for those data snippets in fact. So I think that its entirely reasonable to store a file in the file system and then store a reference to that file in the database along with all the other information we deem necessary. It is true that we do run the risk of orphaning files when we delete or update data. But proper programming practices can alleviate that concern (just as proper db design can alleviate the worry about orphaned relational data in your db). Each to their own, of course, but that's my rational for how I set things up. Cheers, Judah Bill Moseley wrote: > Forget for a minute that it's an image, and instead think it's just > data. Is it integral to the database structure? Is it relational and > has foreign keys pointing at it? What should happen with it's > deleted? > > If they are very large images, eh, blocks of data, then ask your > database provider about how well it handles large data.