Question

I am developing a social networking website and need to figure out a simple and intuitive way to store user-uploaded images on the server filesystem, one that will scale well as the site grows.

What I do is generate a path based on the timestamp of the image upload and name the file with an id corresponding to the record in the database. For example:

/server_img_path/<year>/<month>/<day>/<hour>/<minutes>/<seconds>/<milliseconds>/<img_id>.png

What do you think? Are there any flaws in doing it this way? Are there better ways? Thanks for your advise.

Answer 1

You are storing each file, effectively, in it’s own directory – the only way you would ever end up with two files in the same directory is if they were uploaded at the same millisecond. This will give you:

• a load of pointless inodes
• a filesystem that is a nightmare to navigate when you are maintaining it.

Far better to seperate that data with dashes (-), underscores (_) or not at all.

By all means store your files in seperate directories per-month (or even per-day, if there are enough being uploaded) but going any further than that is probably pointless unless you are, say, Facebook.

Also, beacuse you are including an image ID, the milliseconds at least are pointless. If the ID corresponds to a primary key in a DB table, why not just call your file <id>.png and be done with it?

I would suggest something more like this:

/server_img_path/<year>/<month>/<day>/<hour><minutes><seconds><img_id>.png

…or even better (and simpler)…

/server_img_path/<year>/<month>/<img_id>.png

KISS.