Paul,
Interesting - I don't know which would give better performance, there are too many things I don't know about your set up but here are some general rules I think would apply:
How many files are we talking about? If it's many I think a database is the only way to go.
What happens when you shutdown the app (or it crashes)? If the data is in a DB you should have no problems (yes DB's do get corrupted and you do need to back them up but there are easy tools for this). If everything is in a big array it's gone so you have to write code to store this array and to retrieve it upon startup.
The Array is cached so it's fast... But in fact so is your data in the database after you select it so it could be fast too.
You say:
I'm not sure this is true - can you select information on several files in the same query? A single row select is not all that bad (not as good as hashing an array but it's not a huge hit). Turn on query caching and it won't even have to run the query again.But this means for every file it comes across it needs to do an SQL query to find the description and icon name. Which doesn't seem very efficient.
Will you have a DB there anyway? Do you need one for something else? If so then it's not much more work to use the DB for this too.
You can (if you find it useful) make virtual directories where the files are arranged on the disk as suites you but are presented to the user as if they are in a special directory (which may not exist). This can be useful if your application moves files around - say from an inbox to a read folder then to a delete folder. If you do this all in PHP reading the filesystem you have to move the actual file; if you do this in a database you can leave the file alone and only update the record.
You can also store more information about the files in the database (comments, history, access levels, ...) this could be useful later - if it turns out you have to have a new field and your using the PHP only method you could have a pain implementing it.
If you needed to scale beyond 1 machine the DB solution could track files on several different machines by adding an additional column (for the host of that file) but the PHP only solution would have trouble offering a complete solution (it would see the files on it's machine but not on the others).
Personally I'd use the DB but I know SQL pretty well and I think I would always have a DB available.
Good Luck, feel free to ask more specific questions. Frank
On Apr 23, 2005, at 2:07 PM, php-db-digest-help@xxxxxxxxxxxxx wrote:
From: Paul Reilly <pareilly@xxxxxx> Date: April 23, 2005 2:05:44 PM PDT To: php-db@xxxxxxxxxxxxx Subject: SQL or array ?
I have a quick question about which would the best way to implement something in terms of performance. Using a database, or just creating a big array in memory?
I have a PHP file manager script which creates an array of all files in a directory, and get's their mime types. It then prints these files to the browser with a little image or a word icon etc for word documents.
So the data looks a bit like this:
+------+--------------------+---------------+----------+ | id | mime_type | description | icon | +------+--------------------+---------------+----------+ | 0 | text/html | HTML document | html.png | | 1 | application/msword | Word document | word.png | +------+--------------------+---------------+----------+
But this means for every file it comes across it needs to do an SQL query to find the description and icon name. Which doesn't seem very efficient.
Would it be better to just create a big array at the start of my script with all this data in? That would seem more efficient, and hence faster way of doing it?
Any feedback appreciated.
Paul
