[thelist] Images--database or file

Judah McAuley judah at wiredotter.com
Mon Feb 5 12:47:01 CST 2007

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 

Each to their own, of course, but that's my rational for how I set 
things up.


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.

More information about the thelist mailing list