Re: Database versus filesystem for storing images

Andrew Chernow <pg-job@esilo.com> writes:

>>> Or am
>>>I the only one that is thinking about referential integrity with those files?
> Not at all.  I'm not sure how 3rd party tools like apache, `ls`, `gzip`,
> `find`, nfs, etc... are breaking integrity.  Any php, jsp, C or shell script

For gzip, for example:

    - DB record contains "/some/dir/file.ext"
    - Filesystem contains "/some/dir/file.ext.gz"

NFS can also be guilty if it fails or the server goes down.  If I have a share
mounted as "/some/remote/dir" and I say that the file is at
"/some/remote/dir/file.ext" but the NFS server is down then it is the same as
if the file didn't exist at all since it can't be reached.

For both cases, if the file is inside the database and I am referencing it
then I know that it *is* there.  Referential integrity takes care of that for
me with no cost or any other action of mine.

> you write would be doing the same thing, accessing the data.  All your doing
> is making your system more accessible to a wider range of tools, other than
> your own.

And introducint more failing points.

> Just like you are cautious about not deleting the pg_data folder, big no-no,
> you need to be cautious about not deleting or modifying these image
> files. Basically, the image files are an extension of the database that you
> would glue together.  I think there is a clear separation of tasks here.  I
> think this is required if you were handling any sizeable amounts of data.

So you have added the possibility of manipulating (which is different from
reading or accessing) the files directly but you say "don't touch them!".

> The other thing is the original poster needs apache to access these
> images. This is a requirement of his/her project.  Probably a good idea to

And nothing prevents those files from being served from the database.

> meet those requirements.  It is far more effecient to have apache access
> them

Where weren't we meeting his/her requirements?  All the discussion is around
available means to do that.  One option is having the files on the database,
the other is on the filesystem.  From my understanding we're discussing the
benefits of each one.  Aren't we?

> directly then pounding your database with web requests for image file data.

It might be.  If you can be certain that the image *is* there when it tries to
access it.  Both examples above -- gzip + NFS -- show two ways of having
different things inside the DB and on the FS.

> It is good design, and distribution of tasks, to get the image paths from the
> database and and have apache server the data; select images paths from php or
> something.  Now you can have the data anywhere, on a different server, over an
> nfs mount, gfs, wherever.  Much more flexible and distributed.

And also more uncertain that the referred data is there at all.

--
Jorge Godoy      <jgodoy@gmail.com>