That's what I've been doing with this app for the last 10 years ;) It's just that when you need document/image "portability," the file-system method gets messy from a security standpoint.
Take synchronizing a sub-set of "internal" images and documents to a least-privileged DMZ segment. Doing this from a file-system standpoint gets complex when you do it securely - and besides, storing the image name/path in the DB requires that I replicate both db data and file system data. If I can replicate everything within a single, encrypted connection, that makes things much easier. But I totally agree with static content. All the static content will be file based, as it should. And you actually sparked an idea as I write this-- which would be to securely replicate data to my destinations (my remote facility and to different DMZ segments) but to then extract the data to the filesystem where I can more granularly control access. That's not a bad idea, actually. More complex from a development standpoint, but it nicely addresses the "portability" issue while still taking advantage of strong controls and performance. I'll have to think about that some more. t On 9/20/06 12:33 PM, "matthew patton" <[EMAIL PROTECTED]> spoketh to all: > what makes sense is to store the path to the image file in a database > and then shove that string into the generated HTML. that way the > browser and the static content webserver do what they are good at. > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > --------------------------------------------------------------------------- > --------------------------------------------------------------------------- > > > --------------------------------------------------------------------------- ---------------------------------------------------------------------------
