Question

I have multiple images stored at URLs like: /uploads/hash/IMAGE001.jpg. Using jQuery UI’s sortable(), I want to sort and store the order of the images asynchronously.

I’ve come up with a couple ways to do this, and am curious what the best method would be.

I can create an SQL table for each of the /hash/ directories with 3 columns (ID, IMAGE_URL, IMAGE_INDEX) and update the table’s _INDEX values at every sort. Then, I can grab the sorted list of IMAGE_URLs by querying the database with ORDER BY IMAGE_INDEX.

Another idea I had was to name the files with a preceding 0000 (eg. /uploads/hash/0000IMAGE001.jpg). If I rename the files in PHP at every sort, I can grab the /hash/ directory of images in PHP with opendir() without the SQL overhead, then order by filename at the client or server end.

Would I run into any bottlenecking issues with lots of concurrent file renaming (vs concurrent SQL table updates)? How does the performance of grabbing a directory listing from PHP differ from querying SQL with ORDER BY?

Answer 1

You should sort with a database in this case,

1. The database will build B-tree index and keep sorted for fast retrieval and update.
2. You can make range queries on the file.
3. You can change the storage of the actual file without coupling with the look up.
4. You can scale to a huge number of images with memcachd and sharding on multiple machine

The file system is not designed for sorting and managing change.

1. Though fast when number of file is small, it will take longer and longer time to sort.
2. The image itself is tied intimately to the id, this restrict flexibility.
3. Limit you to one machine, one directory and by the OS limitations, you will have to scale by building this up more and more, end up with building your own pseudo-database.
4. On a server this will be hellish, OS locks and concurrency management is not as sophisticated as db.

Using a DB is the way to do so for any “real” application, using the file system is a quick hack.