> I'm making assumptions about the layout again. The database will > likely already have the table files opened, but will need a seek to > get the data. The webserver will have to do an additional seek (I was > assuming on a far slower drive system, and likely twice for stat and > read). I'm not sure I trust this assessment.If it is an often used image it will be in OS level cache. If it is not, then you will have the I/O. Regardless, it will be using SQL database cache blocks and reduce the efficacy of the SQL cache.
Remember, I don't use a db to store images, for a variety of reasons, mostly in that centralized repositories of anything don't scale. However, if your hardware is far more than than you userbase will need, the SQL server's caching won't matter, and it will be faster. Not that it matters, since it would be a more expensive setup than necessary. Ease of programming wise, or in the one case where we use it: ease of developer setups, it works better. Those are really just configuration issues and a syncing issues across platforms. Storing everything on one machine does not scale. And as to the "slashdot effect" -- snore. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
