Re: Database versus filesystem for storing images

From: Andrew Chernow <andrew(at)esilo(dot)com>
To: Clodoaldo <clodoaldo(dot)pinto(dot)neto(at)gmail(dot)com>
Cc: Jorge Godoy <jgodoy(at)gmail(dot)com>, Andrew Chernow <pg-job(at)esilo(dot)com>, Jeremy Haile <jhaile(at)fastmail(dot)fm>, pgsql-general(at)postgresql(dot)org
Subject: Re: Database versus filesystem for storing images
Date: 2007-01-06 12:48:07
Message-ID: 459F9A87.5010304@esilo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)gmail(dot)com>:
>> Andrew Chernow <pg-job(at)esilo(dot)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,

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Clodoaldo 2007-01-06 13:23:43 Re: Database versus filesystem for storing images
Previous Message Clodoaldo 2007-01-06 12:42:21 Re: Database versus filesystem for storing images