>> 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 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.
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.
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 meet those
requirements. It is far more effecient to have apache access them directly then
pounding your database with web requests for image file data. 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.
Andrew
Jorge Godoy wrote:
> "Jeremy Haile" <jhaile@fastmail.fm> writes:
>
>> Another thing to consider is that storing them in the file system makes
>> it much easier to browse the images using third-party tools, update
>> them, archive them (by gzipping or whatever). This is much more
>> difficult if they are stored in the database.
>
> If you touch the files with third-party tools how are you going to prevent
> that they aren't missing when the database say they are there? If you're
> referencing them somehow, you have to guarantee that they are there... Or am
> I the only one that is thinking about referential integrity with those files?
>