ASP.NET MVC – Storing Images vs Virtual Resizing and Returning Byte Arrays

I am lead developer for a UK-based travel company. One of the projects I implemented was a web version of our image library which can be queried automatically to provide photography for our site. It contains about 150k images, of which about 60-70k are available to the website (the highest rated).

We started off by defining about 5 sizes, creating these size versions on the fly and storing them in Amazon S3. Price was minimal but Amazon is built to fail gracefully, so we'd often see missing images. The more we developed our site, the more we hated only having five sizes of image available.

We moved to a dynamic resize model, in that we can add width and/or height parameters to the URI of any image to have it render in that size on the fly. We cache the resized image (using an MD5 hash of the request URI as filename).

To get image #12345 (our images are fetched via a db, but you could replace this with a file path) at width 200 and jpg quality 80%, the URI format would be:

http://images.domain.com/?imageid=12345&w=200&q=80

This solution was easy to implement and works seamlessly - there is no discernable delay to the website visitor, even on pages with 20-30 images.

We're doing this all with .net, although I've also written a PHP image resize script which does the same thing.

Hope that helps, Adam

I prefer to put binary in the database, but that's primarily because

• I know where it is, and I don't need a systems guy to set up a network share or webserver.
• I can control who can retrieve the data through my application, rather than rely on permissions on the file system. I can do it on a very granular level very easily.
• I get much simpler transactional integrity when inserting files than I would with a file system.

The best argument against database storage are around size - the database might become unmanageable. Much more difficult to do database backups & maintenance; the database is one huge file, whereas if the files are external then you can have some over here and some over there.

If you're using Microsoft, perhaps the best compromise is the FileStream type. It stores the filepath in the database and the files in a folder, but the folder is essentially controlled by SQL. You 'insert' files to the database and they're saved in the folder, and when you 'select' from the database the server will retrieve them from the folder and serve through through the database. In this way you get the best of both worlds - transactions and control, plus the size efficiency of keeping the database small.