An additional reason for storing the images on the disk but not in the database is that some database can't handle large BLOBs very well (MySQL, for example, has had some serious problems with files stored in the DB).
But it CAN be done - you'd upload the file and save in the DB. When you need to display, you extract it from the DB, save it to the disk somewhere and tell the webserver the path to the file.
However, what you normally would do is to upload your user's file, assign it some random name, and save this name in the database.
The code to do this is long, but actually not that complicated. You'll find lots of examples.
Main Topics
Browse All Topics
by: virmaiorPosted on 2006-09-12 at 13:32:57ID: 17506602
hey avo42,
this is actually a bad idea. allow me to explain. the thought that you're having is probalby along on the lines of "wouldn't it be great if i could keep a whole bunch of images in the same place and then bring up whichever one that i wanted?" and track which ones you've brought out, etc., etc.... so it follows that you want to store images in a DB.
But there's one problem. webpages don't show images from DBs; they show them from files...
e.g.
<HTML>
<BODY>
<IMG src="/images/myimage.jpg" alt="">
</BODY>
</HTML>
there's no way around the webserver separately loading images from the page.
so here's the thing, you *can* store images in blobs in a DB.
but to show the image again, you need to setup a script file that serves the content of the image (simulates the file).
this is always going to be slower than just letting the webserver serve the image file itself...
so if you want to use a DB to track images, track the filenames rather than storing the images themselves.