Being probably the most popular NoSQL solutions MongoDB has the majority of the benefits of this method. Only one problem I am still battling with is when reflect object relations in NoSQL data store, particularly - MongoDB.

For instance, let us think about a simple data model: User, Publish and Comment. It's obvious in my experience that comments don't have any value by themselves and therefore become embedded objects for Posts. However when it involves customers - that becomes tricky because User is definitely an entity by itself, not combined with Publish. Now just in case I have to list posts with user full names and links to profiles on the web site, I will have to have a listing of posts and knowledge about posts authors (title and id a minimum of).

I see 2 possible solutions here:

  1. P-normalize the information in ways that every publish entry consists of its author's ID and full title (and then any other user characteristics I would need when listing posts). By doing this I'd make querying for that data rather easy but wheneve user updates his/her profile I will have to update all of the posts through the user too. However I have to also store user characteristics within the comments objects meaning upgrading account basically requires me to update all of the posts which have a minumum of one comment through the user unless of course I wish to store comments inside a separate collections.
  2. Only store user ID within the publish object and run 2 queries: someone to get a listing of posts and the other someone to get listing of customers where user id is incorporated in the listing of publish authors. This involves 2 queries and additional processing during my application code to map customers towards the posts.

I am sure I am not the first facing this problem but regrettably I haven't found any guidelines about this subject to date. Opinions?

Both of them are valid solutions, the benefit of solution 1 is you can show a webpage such as this with locating just one document in the db. Customers don't update their profile very frequently and you will update all posts and embedded comments async following a account is transformed. You are able to index the posts and embedded comments on userid therefore the update ought to be fast. Upgrading in mongodb is extremely fast because mongodb does an update-in-place and also you can't rollback or commit so mongodb does not need to log the alterations.

However customers on sites like stackoverflow in addition have a status which status changes greater than their profile.

Solution 2 necessitates the locating more documents per page, however you should use the $in operator with a listing of userid's (userid of publish+userid's of comments) which means you just have two "chooses claims".

I faced an identical problem and this really is the way i solved it :

(After I solved this problem, my driving motivation ended up being to avoid joins)

use 2 separate collection : one for Customers and something for POSTS. Keep user object together with the publish within the posts collections. Don't update the posts collection once the user object is transformed. keep up with the user details are the Customers collection. Sure the publish data would finish up that contains stale user information but exactly how frequently does the consumer change his/her profile.

If you need to show the complete latest user information together with each posts , then retrieve the consumer information from the cache.

Hope this matches your needs. My option would be still in development so I don't have load test results to express.