Re: Database versus filesystem for storing images - Mailing list pgsql-general

From Andrew Chernow
Subject Re: Database versus filesystem for storing images
Date
Msg-id 459F9A87.5010304@esilo.com
Whole thread Raw
In response to Re: Database versus filesystem for storing images  (Clodoaldo <clodoaldo.pinto.neto@gmail.com>)
List pgsql-general
 >>>apache has very good page and image caching.  You could take advantage
 >>>of that using this technique.

 > I wonder why this HTTP cache headers argument didn't surface in this
 > heated debate.

I did other up this argument by the way.

Andrew


Clodoaldo wrote:
> 2007/1/5, Jorge Godoy <jgodoy@gmail.com>:
>> Andrew Chernow <pg-job@esilo.com> writes:
>> > 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?
>
> Yes, although I suggested two solutions I asked for anything that
> would be considered the best practice. Now I think there is not a best
> practice or better, there should be one best practice for each of the
> solutions.
>
> I have done an intranet application that stored images in the
> database. It worked perfectly and I used the same engine in another
> intranet application to store not only images but any document which
> also worked perfectly.  The decision to go the dabatase only route was
> easy: The filesystem space would have to be negotiated while the space
> occupied by the databases were not controlled and used an advanced
> storage solution that gave lots of terabytes to be used at will. Also
> the any document application should not loose a single document and
> access control should be strictly enforced which was much easier to do
> with the database since I had no control over the webserver and even
> if I had I think the database access is still easier to control than
> the filesystem access. That was in a corporate intranet.
>
> What I'm doing now is an internet application. While the FS x DB
> synchronicity is very important in some kinds of document management,
> it is not in this application. Indeed if a few images are lost each
> day it has no meaning in a 500K to 1M inventory. The offended clients
> just upload them again. No one will be sued. The images are all
> public. No need to control the access.
>
> But the main factor to push me in the file system direction is the
> HTTP cache management. I want the internet web clients and proxies to
> cache the images. The Apache web server has it ready and easy. If the
> images where to be stored in the DB I would have to handle the HTTP
> cache headers myself. Another code layer. Not too big a deal, but if
> Apache give me it for free...
>
> I wonder why this HTTP cache headers argument didn't surface in this
> heated debate. Aren't DB developers/admins aware of the internet
> client's bandwidth limitations? Or they just assume the application
> would handle the HTTP cache headers? In the applications I created for
> intranet bandwidth was almost a non issue and I didn't care to make
> them bandwidth efficient, but for the internet the problem is there
> and it is big.
>
> Regards,

pgsql-general by date:

Previous
From: "nyenyec"
Date:
Subject: Re: GUI tool that can reverse engineering schemas
Next
From: Maurice Aubrey
Date:
Subject: Re: Database versus filesystem for storing images