Also from a deployment and configuration point of view, I find it easier to have fewer location-specific, external dependencies.
you can get around the browser-cache issue by having a servlet that takes URLs that "look like" normal URLs with .gif, .jpeg extensions, using pathExtraInfo instead of query params. -- Bill ----- Original Message ----- From: "Scott Eade" <[EMAIL PROTECTED]> To: "Torque Users List" <[EMAIL PROTECTED]> Sent: Thursday, March 20, 2003 5:37 PM Subject: Re: How to read/write images to/from db > One problem with storing the images as files is that it becomes harder to > dynamically manage the security of the images if the ability to view them > needs to be controlled on a per user basis. > > Most applications won't need to worry about this though. > > Scott > -- > Scott Eade > Backstage Technologies Pty. Ltd. > http://www.backstagetech.com.au > .Mac Chat/AIM: seade at mac dot com > > > On 21/03/2003 12:17 AM, "Dan Allen" <[EMAIL PROTECTED]> wrote: > > > It is pretty much a consensus that storing images in a database is > > an unnecessary overhead, not because the database can't handle BLOBs > > (although the relational aspect of searching and filtering is pretty > > much lost with BLOB fields) but that a browser must issue a new > > request each time you want to dish out an image because there is no > > way for the browser to make a hard cache link. You should store > > only meta data and a file reference in the database, perhaps even > > only a relative file reference in case your data storage location > > changes. > > > > Dan > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
