>> > Not in my environment. All db servers have RAID 10 over 8 SCSI 15K >> > disks. Pulling from them is always faster than a webserver pulling >> > from its SATA drive. >> >> That's not exactly an apples to apples comparison. > > That is true, and sort of the point. Not really, anything that you provide for the database, could equally be used for the image server. > > However, the whole thing started because someone was asking a trivial > question. The assumption there is that they are on a hosted > environment, likely with the the web server and the database on the > same server. Chances are the filesystem will be a better bet for them > for speed. But on such a system, the speed difference may not be much > of a concern. > > Where I am, I am forced to think about different things, so my > viewpoint may be improperly colored. Its completely random that I'm > posting to this list at all... > >> > Also, there is issue of going to the database and going to the >> > filesystem. Timing wise, you >> >> Please explain. > > 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. > >> Putting the files in the DB doesn't always remove extra >> cleanup/management >> stuff. Sometimes the database stores binary objects as files and >> sometimes >> they don't get deleted correctly. > > I'm dying to know what database you are using that puts every blob in > a separate file these days. > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
