MySQL vs Folder/file fetching

nrg_alpha

This may in actuality be a ridiculous question (but then again, I'm used to asking those kind of questions 😉 ).

Currently, I am using PHP to go into folders and fetch filenames for the purpose of displaying thumbnail / full sized images. So this means things like declaring a folder path, 'glob'ing for certain file names, etc..

Since I am now staring to learn MySQL, I am wondering which method is 'better' (I typically ask with regards to speed / efficiency, but since we are talking about a rough grand total of about 20 thumbnails / fullsized images here, I'm going to fathom a guess and say that speed is most likely negligible (but I welcome a different answer if this is not the case)).

Is it better overall to deal with going into folders and fetching file names, or is it best to set up a small lightweight database which contains folder paths/file names and go off of that?

One advantage to the file setup I have is that it is truly automated (I simply add my thumbnail and full-sized image into the appropriate folders, and PHP automatically handles the rest (where as if I go the database approach, I not only have to update the folders with the images, I also have to update the database as well). But from a coding standards point of view, which would you guys go with? (I realize that I have to be careful with security issues such as MySQL injection attacks and such should I go the database route... and am more than willing to research and deal with this sort of things).

Cheers,

NRG

cahva

Well it depends how much files and folders are we talking about. I personally have seen a site taking a server down by a blog software(SimplePHPblog) which depends on files and folders. It had folders by date and posts as text files inside them. When the site grow popularity and aged, it had several hundreds of these files. Couple of simultaneous users could easily hog the servers resources and server became unresponsive.

That said, I think you just have to test yourself. Watch how much resources is the site taking. One thing you should definately do is use some caching so there wont be any un-necessary fetching for the files if the directories contens have not been changed. Caching is quite trivial to do and you can use readymade caching solutions like Zend's cache which is part of their framework.

nrg_alpha

I am only dealing with 2 subfolders, each with a maximum of ten thumbnails and ten fullsized images (so this is nothing even remotely close to some kind of massive blog system or anything like that).

I'll have to make a test database and try seeing how that route works out.

bpat1434

Well, there are two views here. Yes, it can be done if you have a caching mechanism and your server isn't dynamically resizing images all the time; however, the issue comes to scalability.

Think of it this way. If you know you're going to eventually have more than 2 folders with 10 images each, then you might find it faster to use a database because all you're doing is simple queries. But if it will always be a static number of images and a static number of folders, then the question is load. How many hits-per-day and even hits-per-hour will your site take? At what point is your server going to just say "no more" and stop working?

So to answer the question as to whether to use mySQL or a database, you really need to answer 3 questions.

Will my data be static or will I be adding/removing items as I go on?
Is it feasible for me to implement a caching scheme using a flat-file system or is a database easier?
How much load can my server take before it quits?

Usually the second question is answered with "yes, using a database and simple html files"; but, not always.

For something this small, I'd say keep with the file system, until it grows. If you start to see it grow, then you need to cut your losses and move to a database type setup.

nrg_alpha

Hi bpat..

I have no plans for the system to grow..basically, the max amount of thumbnails and fullsized images is 10 each per subfolder (2 subfolders).

So to answer your posed questions:

Will my data be static or will I be adding/removing items as I go on?

I be adding/replacing items as I go, as once a subfolder fills up with 10 gallery images, and a new image is ready, I will replace the 'weakest quality' image with the newest addition (in otherwords, there is no plans to expand past 10 thumbnail images and 10 fullsized images per subfolder).

Is it feasible for me to implement a caching scheme using a flat-file system or is a database easier?

It can go either way for me (depending on the ultimate path I take).

How much load can my server take before it quits?

Good question. However, I do not anticipate any high volume traffic at all. The site is built for occasional viewing.

For something this small, I'd say keep with the file system, until it grows. If you start to see it grow, then you need to cut your losses and move to a database type setup.

Again, there is no plans for growth. However, I would still be interested in building a test page that utilizes a small and simple database if its more beneficial to do so.