A while ago a friend of mine asked me how I would go about building a ‘People Who Like This Also Like …’ feature for a music startup he was working at. For each band or musician, he wanted to display a list of other artists that people might also be interested in.
Like most NoSQL solutions, RavenDB best practices favor denormalization over composition / joins for complex documents.
That decision make reading the data very fast and easy, but it present a challenge when we need to update the Artist name. In general, it isn’t recommended to denormalize data that frequently changes, but even rarely changing properties will change occasionally. In order to solve this exact problem RavenDB offers Set Based Operations.
One thing that confuses a lot of people when they dive into RavenDB, is how to handle relations and references between documents. RavenDB is a document database and thus is certainly not built around the idea of relations. Instead, most of the advantages of document databases come from the document oriented modeling, which treats every single document as isolated and meaningful on its own, therefore reducing the number of request to the database (in order to serve a web request for instance) and enabling easy horizontal scaling (sharding across multiple servers).