NoSQL vs Linq To Objects for asp.net mvc

Is there any advantage to using a NoSQL database of some sort as opposed to just keeping a big object cache in HttpCache and using linq to objects to query stuff?

We have a list of 5000 products that need to be served up to users based on geography, user preferences, etc. 开发者_JAVA技巧The canonical product data lives in a relational db and we don't intend to change that. We have a sproc that returns a big list of valid product Ids for a given customer, but we don't want the overhead of reloading each product for each customer. (Why ship the same product description between the db server and the web server?)

Accordingly, we just fetch the product details from cache for a given list of Product Ids.

Our first attempt to cache products led to huge memory usage as the app made multiple ToList() calls because of bad query design and sluggish garbage collection.

I'm looking at building a new version and would appreciate any suggestions as to whether a NoSQL database offers any real advantages over just using linq to objects.

If your relational database is SQL Server, you can use Notification Services and store the product list using a SqlDataSource with EnableCaching="True" and CacheDuration="Infinite" The advantage of this approach is that you'll get a round-trip to the database only if the product list is modified.

Take a look at this article, it explains how Notification Services works.

At 5000 objects the HttpRuntime.Cache is a great NoSQL data store.