On Mon, 2007-06-18 at 11:25 -0400, Daniel Brown wrote: > On 6/18/07, Tijnema <tijnema@xxxxxxxxx> wrote: > > On 6/18/07, Daniel Brown <parasane@xxxxxxxxx> wrote: > > > > > Referring to one of my earlier posts in this thread, as a > > > > > refresher, database information is stored in files. So to store files > > > > > in a database means the following has to take place: > > > > > > > > > > 1.) Data is uploaded to the server. > > > > > 2.) Data is processed by the database server. > > > > > 3.) Data is compressed and encrypted. > > > > > 4.) Data is written to disk. > > > > > (4b. - optional) Data file is checked for integrity and > > > > > correctness of write. > > > > > > > > > > Then, to serve the content, a similar reverse occurs: > > > > > > > > > > 1.) Request is sent to the server via a script. > > > > > 2.) The script interfaces with the database to locate the > > > > > desired data row. > > > > > 3.) Once located, the data is pulled in raw form from the database file. > > > > > 4.) The data is then decompressed and decrypted. > > > > > 5.) The data is streamed back to the script. > > > > > 6.) The script decides how to handle it, based upon hard-coded options. > > > > > > > > > > For a filesystem, it's simpler. Uploading: > > > > > > > > > > 1.) Data is uploaded. > > > > > 2.) Data is written to disk. This isn't quite correct. There are numerous databases that allow you to assign a raw partition and they manage the filesystem themselves thus the intermediate OS dependence is eliminated. As such, the database probably wins in this situation since you also get rapid searching on any meta data fields and since you probably have to issue a query anyways (for either approach), this approach is superior since you no longer need to interact with the filesystem at all. The only negative is that writing to the database will be less efficient due to escaping of the data. But reading will be much faster. And in practice, I'd wager, it's rare that images are created more often than read. Cheers, Rob. -- .------------------------------------------------------------. | InterJinn Application Framework - http://www.interjinn.com | :------------------------------------------------------------: | An application and templating framework for PHP. Boasting | | a powerful, scalable system for accessing system services | | such as forms, properties, sessions, and caches. InterJinn | | also provides an extremely flexible architecture for | | creating re-usable components quickly and easily. | `------------------------------------------------------------' -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
