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
[office] (570-) 587-7080 Ext. 272
[mobile] (570-) 766-8107
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
