[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
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.
More information about the thelist
mailing list