MongoDB Schema Design Confusion

help
1

I’m working on a photo collecting app with Meteor. It’s simple: people are grouped into project and then they collect photos for that project. There are many relationships in this app, one-to-one, one-to-many and many-to-many.

I’ve learned a bit about MongoDB schema design. The core idea is you should make decisions (e.g. embedding vs referencing) based on how your app use the data. In this case, for example, I find it better to embed photos into projects because mostly they are used together.

However, according to the Denormalization chapter on Discover Meteor, Meteor supports document level operation better thus making it a preferable way to referencing than embedding. As a result I just reference everything and feels like I’m using SQL without utilizing the flexibility of MongoDB.

What are your experience with schema design in Meteor? Am I missing something or these are just limitations in Meteor that I have to live with?

2

Do your relational data models as usual. Just be sure to encode them in the document schema, instead of the collection schema. Collections schemas should be optimized for data access and data transfer (usually 1 document per page/view).

3

I found that you do not need to enforce mongo specific things if your app does not need it.
Just find out how to minimize queries and data transfer. If it ends up like a standard SQL structure, no worries.