Question

In relational database, 1-n n-n relationships mean 2 or more tables.
But in mongoDB, since it is possible to directly store those things into one model like this:

Article{
  content: String, 
  uid: String,
  comments:[Comment]
}

I am getting confused about how to manage those relations. For example, in article-comments model, should I directly store all the comments into the article model and then read out the entire article object into JSON every time? But what if the comments grow really large? Like if there is 1,000 comments in an article object, will such strategy make the GET process very slow every time?

Answer 1

I am by no means an expert on this, however I’ve worked through similar situations before.

From the few demos I’ve seen yes you should store all the comments directly in line. This is going to give you the best performance (unless you’re expecting some ridiculous amount of comments). This way you have everything in your document.

In the future if things start going great and you do notice things going slower you could do a few things. You Could look to store the latest (insert arbitrary number) of comments with a reference to where the other comments are stored, then map-reduce old comments out into a “bucket” to keep loading times quick.

However initially I’d store it in one document.

So would have a model that looked maybe something like this:

Article{    
    content: String, 
    uid: String,
    comments:[
        {"comment":"hi", "user":"jack"},
        {"comment":"hi", "user":"jack"},
    ]
    "oldCommentsIdentifier":12345
}

Then only have oldCommentsIdentifier populated if you did move comments out of your comment string, however I really wouldn’t do this for less then 1000 comments and maybe even more. Would take a bit of testing here to see what the “sweet” spot would be.