Re: Database versus filesystem for storing images

> And introducint more failing points.
depends on how you do it. not everything has to go in a database to be
reliable. Part of good engineering is realizing when to use a tool and when not
to.

I think a 10K view of the issue is in order. The bigger picture is being
missed, or I am not communicating well.

I bet if I gave you a million dollars, you could implement what I proposed; in a
reliable, redundant fasion. You could probably convince anyone of its merits,
making my case for me. All you would have to do is entertain the idea ... I
mean you sound smart enough ... probably smarter than me :)

andrew

Jorge Godoy wrote:
> Andrew Chernow <pg-job(at)esilo(dot)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.
>