>the blob field can't be indexed but others (id, filename, keywords, >caption etc..) can, there's lots of cases where it makes sense to put >images in a database.
This makes no sense to me. You would still index the filename, the keywords, the caption, make them all searchable, but you do *NOT* shove the image data into a BLOB to do that. The image raster pixel data and the meta-info about the image are completely orthogonal. When you start using SQL to dig into the actual image data, parsing the GIF LZW compression within it (or JPEG, or whatever) and comparing the actual contents of the images in SQL, it makes sense to shove the images into a BLOB for index/search reasons. Now, network traffic and off-loading some work from your web-server to your db-server *MIGHT* *MIGHT* *MIGHT* make sense, but I sure doubt it for *most* users/applications. If you've got an actual two-tier solution with real-world performance testing where it makes sense, post the numbers and any other rules of thumb for when you really, really do want GIF BLOBs, by all means. -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
