>> > >> The web browser sees an image as a single HTTP request. Invoking >> the PHP >> > >> script engine, parsing the script, and executing a SQL query to >> retrieve >> > >> the image from the database is less efficient than letting the web >> > >> server >> > >> just send the file. > > > In a simple setup, that is probably true. However, if you use PHP to > do authentication or throttling, then the engine is already there. On > the flip side, you can use sendfile() or on Lighhttpd you can push the > sending of the file back to the webserver using x-sendfile. That's doesn't address the storage location of the file. > > >> > >> Image files do not need to be constrained by the rigid requirements >> of a >> > >> relational database. > > > File systems are not immune to constraints. For example, ext3 only > allows 32000 subdirectories. So if you gave each user a directory to > upload files to, you would be stuck at a max of 32000 users. Or start > going to silly things like /S/t/e/Steve.gif First of all, I wouldn't use EXT3 for anything. In is, in all my tests, the slowest file system. > > More constaints below.. > > >> > > What about when you need to share those files across a 50 node >> network? > > > Webfarm scenarios do come to mind. There is an issue of how to sync > all webservers to have all files. Then again, if you are using 50 > webservers, the chances of them all being able to house all your files > (1 petabyte, as an example given) is not very good. Again, the problem of replication or distribution does not require a database. If you are saying that your single database will contain all your bitmap files, then that's messed up and your database will be a bottleneck. You've stated a problem: A large amount of data spread across multiple machines, this is a real problem domain, but it absolutely does not say why a database is the right solution or even a solution at all. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
