On 6/18/07, Daniel Brown <parasane@xxxxxxxxx> wrote:
On 6/18/07, Tijnema <tijnema@xxxxxxxxx> wrote: > On 6/18/07, Daniel Brown <parasane@xxxxxxxxx> wrote: > > On 6/18/07, Colin Guthrie <gmane@xxxxxxxxxxxxxx> wrote: > > > clive wrote: > > > >> > > > >> I have no clue how big the files are, but you might want to store them > > > >> in a database. That can speed up things, but don't ask me how much ;) > > > >> > > > >> Tijnema > > > >> > > > > no dude, while database are convenient, files systems are faster, I mean > > > > thats what they were designed for, serving files. > > > > > > > > For lots of files I would store them in directories and sub directories. > > > > > > Yeah amen! > > > > > > I generally use a two character hex hash in my main folder to give 255 > > > sub folders each containing files. > > > > > > In my case the hash is calculated from some known info - e.g. a database > > > ID and then stored in a meta data table. > > > > > > Col > > > > > > -- > > > PHP General Mailing List (http://www.php.net/) > > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > > > > > > Tij, > > > > 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. > > > > Serving: > > > > 1.) Request is sent via script, FTP, socket connection, or > > local request. > > 2.) File is served through via the method requested. > > > > So there are several pros and cons for each, but just to list > > three of each with regard to database storage: > > > > Pros: > > Can be stored centralized and portable, without needing to archive. > > Automatically encrypted and compressed upon storage. > > Easier and faster to search. > > Cons: > > Slower storage and retrieval > > Much greater risk of corruption > > Not always cross-compatible across platforms, versions, > > installations, etc. > > > > -- > > Daniel P. Brown > > How sure are you about all this? > Benchmarks? > > What about search time for the harddrives etc? It needs to scan the > inode table to find the file, etc.., then it needs to locate that file > on the harddrive, while the second file might be on the other side of > the disk.... > > Storing all files in one single filesystem means you have only 1 inode > :) All data is stored at same place (atleast, it should be) > > Tijnema > Do I have benchmarks? No. Do I have the time to do them now? No. Do I feel confident enough that if you were to run those benchmark tests that it would prove me right? Damn straight. ;-P -- Daniel P. Brown
I think I have some time to write a simple script in a few hours, I'd like to see what the performance difference is :) Tijnema -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
