How do you store images for asp.net application?

Question

We are just upgrading our ASP.Net shop implementation (from simple one) to structure that should be more flexible. I am just looking for some options how to store images related to product. (there will be two types of images, thumb of the product and then full view images of the product). It should handle at least hundred products.

So far I am thinking about two options:
1) store images in db - images are loaded from Db into stream then into image (displayed by using IHttpHandler)
Pros
- The image itself is part of class, business object which we are working with in code behind
- one place to maintain product data
Cons
- memory consumption - traffic increase as we get the product data from other API

2) store images in file system - images are put in page as link
Pros
- none impact on memory as it is not stored in session, app cache.It is used like simple link
- no memory consumption
Cons
- needs to keep some name convention for images in File system (perhaps even some folder structure)
- more complicated maintenance of images

Is there any other suitable mechanism? What would you advice to use?

Personally I prefer images in file system, but it can be harder to maintain it as there are two separate places.

Thanks for any comment. X.

BTW: I can really imagine that in some stage the product will also have some videos or any other media that need to be displayed too. In this case Db is not really option, isn't it?

Answer 1

I guess you have covered anything. You can store the main image in filesystem/db but you can generate the thumbnails on the fly programatically, which would reduce some disk space.

Answer 2

i think mixture of both is the best, for small critical image db is preferable and for large in amount and size file system is better

Answer 3

In instances like your example, where I work we tend to store the images on the disk, and then keep a record of the filename in the db.

Then when you have a db of your products, you can look up and dynamically load your image per product.

This also is quite nice if you have an admin system for adding/removing/editing products.

I suppose it's kind of in between your two original suggestions, you can even store all the images in the same directory this way if you like.

Answer 4

I made a system similiar to this. In my opinion, page load speed trumps all other considerations so I went with the 'store images on disk' option.

When images are added to the system, the original image is cropped and resized to the desired display size for browsing and a thumbnail is also generated. Three images are then stored to disk, the original, the display size and the thumbnail. Each one has a GUID generated for its filename.

(Imagine shopping on amazon, when you a browsing a list of products only the thumbnail is visible. When you inspect a product its display size is shown, and you can usually click on the image again to see the full size.)

I had a database table that looked a bit like this.

ID                int, PK
FullSizePath      varchar(128)
DisplaySizePath   varchar(128)
ThumbNailPath     varchar(128)
OriginalData      BLOB

I kept the original data in the db just incase there was an accident on the file server and the images got deleted, so they could all be re-generated. But this data is never pulled from the db during a page request.

Answer 5

If you are using MS SQL 2008, you have an option for the FILESTREAM feature.

Here's the gist, but you should read the whole white paper:

FILESTREAM is a new feature in the SQL Server 2008 release. It allows structured data to be stored in the database and associated unstructured (i.e., BLOB) data to be stored directly in the NTFS file system. You can then access the BLOB data through the high-performance Win32® streaming APIs, rather than having to pay the performance penalty of accessing BLOB data through SQL Server.

FILESTREAM maintains transactional consistency between the structured and unstructured data at all times, even allowing point-in-time recovery of FILESTREAM data using log backups. Consistency is maintained automatically by SQL Server and does not require any custom logic in the application. The FILESTREAM mechanism does this by maintaining the equivalent of a database transaction log, which has many of the same management requirements (described in more details in the “Configuring FILESTREAM Garbage Collection” section later in this white paper). The combination of the database’s transaction log along with the FILESTREAM transaction log allows the FILESTREAM and structured data to be transactionally recovered correctly.