Assuming you're talking about user uploaded images or something
similar, there are of course different opinions on the "best" way but
here are my thoughts:
1.) You are absolutely right not to store uploaded images in the
application directory. They are external data just like data in a
database.
2.) As far as actually storing BLOBs in the DB, it's definitely worth
considering. The pros are a lack of synchronization issues between
records that represent image files with the actual files on disk and
of course not having to deal with the file system period (no unique
file name issues, images get backed up with the rest of your data,
etc.). The cons are a lack of standardized access (or no access) to
BLOBs through O/RM frameworks, varying support among RDMS's / JDBC
drivers, and performance overhead. If you're building a high-volume
site, you really want to be able to serve images from a dedicated
media server like a stripped-down Apache, Boa, kHTTPd, etc. and you
can't easily do that if your images are in a database.
As much as I like the idea of storing images directly in the
database, I've always ended up using objects/records that represent
files (via a relative file path + a global root path) and storing the
files themselves in a directory structure outside the application.
3.) Buy Kent Tong's book, "Enjoying Web Development with Tapestry"
and read the chapter on building an image upload/download service.
It's really not very hard, but it's too much to squeeze into an email.
HTH,
-Ryan
On Oct 17, 2006, at 5:54 PM, Gabriel Lozano wrote:
Hi all
I want some help on this issue:
I want to know which is the best way to work with images. If I
saved them on
a folder inside the application, the next time I deploy the
application I
will loose all the images. I was thinking on saving them in the db,
but I
dont know how can I retrieve them and show them in the html. If I
generate a
temp file per request, then I will end up with a file representing
an image
for everytime the image is requested.
Any help would be welcome, I was looking for this and I didnt find
anything
on this topic.
Gabriel Lozano M.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
