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.
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.
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).