Don't mistake client side cache with FS / WebServer cache. Also, take into consideration that getting an image from FS is much More efficient than from MySQL so why go there?
As for order, that's really not a problem as you can build a simple Directory hierarchy such as : /home/MySite/images/b/be/berber.gif We handle more than 20M images and files with no problem this way. berber -----Original Message----- From: tedd [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 01, 2006 4:23 PM To: php-general@lists.php.net Cc: Kevin Waterson Subject: Re: [PHP] image uploads Hi gang: I don't mean to offend anyone, but I'm going to side with Keith Waterson about storing images in a dB rather than in a file system. My reasons are pretty simple. First, an image is nothing more than a large of string text -- sure it's voluminous, but there's no difference how it is stored -- either in a dB or fs, it's still all just 1's and 0's stored on a hard drive. Second, when you search MySQL, you're not searching blobs (hopefully) -- instead you are searching the index. What is attached to the index has NO effect on a search. Third, MySQL search routines are simply binary-trees. The indexes are simply pointers to the data stored on a hard drive -- no more, no less than placing url's in a dB and using those as "pointers" to the image stored on a file system -- which may actually take more time resolve. Forth, with respect to the argument of caching the images, your browser doesn't know how images are provided. The image is coming from a simple <img> tag or a header file and the browser simply looks at what's there and compares it with what it has and loads the image accordingly. If you want to store your images in a file system, then that's fine -- but as the number of those images climb, you're going to need a way to organize and handle those images -- and that sounds like a problem that a dB can solve. I can understand image storage being something somewhat problematic. It's not abundantly clear what is actually going on when you store an image. People have impressions that BLOBs are huge attachments that "slow" down dB operations because of their size and when you delete one, there's a huge hole left in your dB. But, those are just unfounded fears, which IMO are reenforced by people's problematic experiences in trying to get things to work. For example, I have read numerous times in the archives and on the net that there is no way to consolidate a MySQL dB after you have deletions. The holes in your dB will remain. But that's not true, while it may not be the best to consolidate a table, it can be done with a single line of code. It's claims like this that add to the confusion of how you can use MySQL and thus create the illusion that you shouldn't use MySQL to store images. But, until someone provides me concrete evidence that MySQL can't handle images as well, or better than a file system, then I'll consider the claim to be an urban myth based upon people not really understanding MySQL. tedd -- ---------------------------------------------------------------------------- ---- http://sperling.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
