Whether to store images in a database or not has been much talked about on the MySQL lists. The general consensus seems to be that you should store the image files in a filesystem since that's what a filesystem is designed for and store the html links to the images in a database since they're data for your program and that's what a database is for.
database systems would be faster than a file system at reading in image data for small images in quick succession. reason is that the db can read ahead in blocks, and will be working from maybe a couple of file system files. if you open/read/close 100 images from a file system, that's approx 100 seek operations on the disk, besides the 100 open/close OS overheads. And since you also store the image metadata (e.g. timestamp etc.) in the same db table, retrieving the right 100 images is a single sql statement. storing same images with timestamped directories/files or whatever concocted method, means that you have to write silly code just to get the right image filenames/files.
i think that all that the thread poster wanted was a method for displaying the images from the database through a webserver. i believe that "multi-part" html page will do that, you just keep printing the next jpeg. the exact method/code is described in the book "Programming Web graphics with Perl and GNU software".
the hardest line to type correctly is: stty erase ^H