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
