On 6/18/07, Daniel Brown <[EMAIL PROTECTED]> wrote:
On 6/18/07, Tijnema <[EMAIL PROTECTED]> wrote:
> On 6/18/07, Daniel Brown <[EMAIL PROTECTED]> wrote:
> > On 6/18/07, Colin Guthrie <[EMAIL PROTECTED]> 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
