>if there's a general rule on whether one should stick > such things into a db or onto the file system.
Where to stick uploads always tends to spark debate from both sides. (I see there are already a bunch of replies. ;-) Personally, the debaute leaves me thinking that either [religion] has it's benefits/problems and there isn't a clear winner. (Unless you've got some hard and fast environ req't.) > putting them on > the fs seems to interfere with clustering Yep. I've seen some systems where the file system area made writeable for 'uploads' is actually shared across the cluster to avoid that problem. But then, you still have potential for concurrency issues if multiple CGI/Servlet/Gerbils try to manipulate the file. I'm no expert, but Unix Filesystems have let me shoot myself in the foot more times than I care to recall. ;-) > putting them in the db puts > extra load on the db and the network. there are a bunch of other issues too. Yep and Yep. No clear winner IMHO. Another possible DB issue... cache. Say the files are images, webserver and FS will automagically handle cache, but if served dynamically -- your image server cgi/servlet will have to deal with that, or worse, just dynamically serve the images over and over again. The client can't cache either, if the server doesn't play nice and give back HEAD data. And even if it does play nice, your server will have to run a DB query to see if the image is updated from the last time the user was there. I'm currently thinking about serving some images stored in a DB via FS by rigging the 404 error handler into a custom server piece that pulls down images from a DB and stores them in the FS, and then the next request won't be a 404. Fun hack, eh. Timo --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
