Data modeling question


#1

Hello everyone,

Meteor is using MongoDB but from what I read, there are best practices of modeling our data that are often not the same as the best practice used in MongoDB. A basic example of this is Many to One relationship, MongoDB best practices is to store them into a list of sub documents. But in Meteor, because of the pub sub, it is prefered to do it in 2 differents collections with the childrens having the id of the parent.

Now let’s get to my case, a One to One relationship. I have Users that need to have a profile (that is not often updated).
Based on this profile, Users are matched (by comparing some data in those profiles).
Is it preferable to store the Profile in the User collection (and how to in this case ?) or the Profile in its own Collection ?
My personal preference is the Profile in its own Collection because I will do a lot on queries on them and that I don’t need the informations in the Users Collection. When I’ll need it, I’ll fetch the User with the UserId.

What do you think ?

Thanks.


#2

In this case mongodb recommends that you embed your profile document in your user collection. The read performance is not impacted, and you use your queries to specify which fields you want to have returned.
I found the free courses that mongodb offers through their university to be very helpful in wrapping my head around these topics.


#3

I agree with @llnathanll: in your case embedding profiles in users looks like the way to go.

That sounds totally wrong to me. Where did you read that?


#4

I read it on the Discover Meteor Book.
They said it is preferable so that we can subscribe on two different collections and only receive update on what we want. If we put to much information in a single document, it will always update and we will need to check what was updated instead of just separating the data that we need to monitor (example : Notifications or Messages not in the profile).


#5

It’s almost always dependent on the situation. It’s not always right to denormalize your data just because you’re using MongoDB. Take a look at this, I asked a question with possible solutions: http://stackoverflow.com/questions/25344444/best-model-for-representing-many-to-many-relationships-with-attributes-in-mongod