2008/9/30 Frank Wiles <[EMAIL PROTECTED]>: > On Mon, 29 Sep 2008 22:16:12 +0200 > André Warnier <[EMAIL PROTECTED]> wrote: > >> We have also looked at various data organisations over time. >> Regarding storing large objects directly in a database, the one issue >> is always that (because of the object sizes), it makes any operation >> on the rows of such a database or table very heavy. Imagine having >> to dump or reload a table that contains 500,000 "blobs" of 2-3 MB >> each. (Don't know about PostgreSQL, but many db systems require a >> dump and a reload when you change a table structure). > > FYI PostgreSQL doesn't require a dump/reload when altering the table > structure. > >> Oh, and I've thought of another advantage, in an Apache/web context : >> to send the content of a file to a browser, you can take advantage of >> the sendfile() call, which is very efficient. Now if your file is a >> blob in a row of a database, you have to read it yourself in memory, >> and send it, don't you ? > > That is one advantage, but I'm going to take it a step further and say > by having the files outside of the database you don't even need Apache, > but should in fact use a lighter weight web server like tux, nginx, or > lighttpd for serving up static media like that.
A newbie question in the insightful thread. Can serving static files and cookie authentication go together? If yes, any hints. Second what are the sizes at which one should start moving to files. e.g. how about plain text blog entries containing no more than say 5 KBytes. Thanks, Himanshu > > ------------------------------------------------------- > Frank Wiles, Revolution Systems, LLC. > Personal : [EMAIL PROTECTED] http://www.wiles.org > Work : [EMAIL PROTECTED] http://www.revsys.com > >
