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: