Store images to SQL database vs file system

  MS SQL 2005/2008
  ASP.NET (C#) 2.0/3.x

We are developing a classifieds type website where a user can upload 1 to 5 images. Each image will be less than 50K in size, and will have thumbnails created for each image uploaded. Some of the benifits of using SQL database to store images, deleting a user record, the users images can be deleted at the same time. This helps with backup issues and orphan images are addressed also.

Does it make sense performance-wise to go in this direction rather than storing the images in the file system?

In this type of site, what would be the most effecient way to retrieve multiple images at once to show on a page. An example would be where a website user clicks on an ad, and the page would serve up the ad text and any thumbnail images related to that ad ID, and each would be clickable to view the larger image. I have done this storing images in the file system, but I'm a little fuzzy on retrieving multiple thumbnail images and also links to the larger images from a SQL server.

Also, should thumbnails be created and stored as seperate images in the database or generated on the fly when the page is requested?

Thanks Lots!
Who is Participating?
Mark WillsConnect With a Mentor Topic AdvisorCommented:
Definitely outside the database...

Even MS have recognised it and created a new type/function, FILESTREAM as acperkins mentions above. It is good, but it also means that SQL Server "OWNS" the images. They are stored externally, but considered part of the database "suite" so to speak. Meaning included in backups and all that stuff without bloating the actual database. It is a slightly different approach, and does take a bit of management, for a start the SQL Server service owner effectively becomes the owner, so it does require a bit of planning.

I still prefer external files when they are more "user bound" images. For example, a product image from the inventory master is ideally suited to FILESTREAM, we as user supplied images can be more easily managed over a shared network drive space.

The other thing is if external packages need to interact with the image. FILESTREAM is really a finished goods type proposition, true it can manage versions a lot better, but is more of a submission of "here it is" and the resulting file is no longer recognised (well by name at least) - SQL does it's own thing with the actual files.

So, horses for courses as to when filestream is best used over external files with a path held in the database. Main thing is "who is going to own the file" and may well depend on how other applications are going to interact with it.

In your case, being classifieds, it would be a toss of the coin. There are distinct advantages in using FILESTREAM, after all it is like an inventory type system, and will be backed up as well, and then there are flexibilities in external images. Over the web, you need to consider speed and traffic. With SQL being the owner, it will also be delivering the image. Externally, you might be able to get away with an image library on the web server and relieve some network traffic.

Bottom line. External - your choice filestream or flat files with a path in the DB - either way.

here is some other links for you :

MS details :
intro / discussion :   (might need to register, and is worthwhile)
with samples :
Anthony PerkinsConnect With a Mentor Commented:
If you are using SQL Server 2008, then there is a hybrid approach using the new FILESTREAM data type.  Take a look at this article:
SQL Server 2008: The New Data Types
Mark WillsConnect With a Mentor Topic AdvisorCommented:
Oh, and just so you are not feeling alone, have a search in EE for Filestream and sort by date - there is quite a lot of good reading, and fixes, and help, and code examples...

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.