Placing Thumbnail Images in the Database

In my entry titled .NET RIA Data Services & Images, it was pointed out that the July Preview of .NET RIA Data Services did not handle database images stored in the database very well (it produced large files returned to the client). It was also pointed out that this situation was being addressed and would be resolved.

Placing actual images into the database is generally not a good idea. Instead, storing URI’s to the actual file in the database is generally a better idea. Using this approach, the images can be easily changed without impacting the actual database. In addition, one can avoid downloading the larger image bits if the image is not used by the application. [Note that Silverlight components, like the DataGrid, do not work with public anonymous types, so generally the entire entity, including any images, are downloaded to the client.]

So you might ask “Why did I include the thumbnail images in the database?” The answer is simple; I didn’t. I was using the AdventureWorks Lite database provided by Microsoft. In the Product table, there are two fields defined that deal with the product images:


While this design may have been OK for relational database queries, where a subset of fields could be retrieved, but it presents a problem for other technologies where the only practical choice is to retrieve all the fields.

Perhaps the best solution would be to work within Silverlight to make it possible to bind a DataGrid (or other components) to a public anonymous type (such as a subset of the properties of the Product entity).


2 Responses to “Placing Thumbnail Images in the Database”

  1.   Burrows Says:

    The Entity Framework (V1) supports what the Product Team calls “Deferred Loading”. What they mean by this is the loading of related entities must be done explicitly, not implicitly. That means that if you query Entity A and want a property from a related entity B, you must explicitly use the LOAD method to get the related entity B. “Lazy loading” generally is interpreted to mean that the related entity is loaded implicitly. See EF Product Manager Tim Mallalieu’s blog post (

    Regardless, I don’t think either “deferred” or “eager” loading helps in the embedded image issue since the image is a part of the entity (in the case of AdventureWorks Products ) and thus is a property of the entity, not stored in another related entity. That is, “differed loading” works with entities, not with specific properties of the entity.

  2.   LexarDS Says:

    Even when storing the images in the DB might seem easier, especially if working in a ntier scenario, saving just the path and filename wil give much more flexibility, glad your info eforces my theory.

    But in the case where the image is stored in the DB, Doesnt the entity model have something like lazy loading for properties, or doesnt it make any difference?


Leave a Reply