I'd like to understand the best practice for small databases. For example, say at Contoso University we know there are only going to be a few hundred or a few thousand students and courses. So all the data would comfortably fit in memory. So then is it better to use an in-memory collection and avoid potentially high-latency database operations? If so, how to periodically write the data to storage?
I am thinking of small-scale production web sites deployed to Windows Azure. Thanks.
Size is only one consideration. NoSQL often has an advantage over RDBs with large unstructured data sets. If you need relational constraints, transactions and other features not supplied by NoSQL products, then you need a relational DB.
I’m working on a sample of my MovieDB (intro to MVC 5) that uses Azure caching and SQL Server. We are working other samples that use NoSQL, Azure Table Storage, Blobs, etc
Sounds good, Rick. I'm looking forward to it.
The particular scenario I am thinking of has a few thousand records that are read-only, although users can create their own items too.
Think of a collection of movies, albums or song lyrics that has been assembled from a list of a few thousand popular titles. The user can browse the collection (read-only), and most of the time they find what they are looking for there. However the user can also add their own records.
Since the data fits in memory, and most of it is read-only, is it maybe better not to use a database for the popular titles.