Data Modelling – Reference or Embedded – Frequent Updates

Hi All,

I’m wondering if my data modeling is okay, or if I should used embedded documents for parts of the data.

Here’s what I have:
My application has users that have X number of boards that have X number of cards. The boards can be private, public or shared with X users.

Currently I’m thinking of 3 separate collections:

User

[{
   id: 123,
   email: "test@test.com",
   password: "1234"
},
...
]

Board

[{
   id: 646,
   name: "This is the name",
   owner: 123, // reference to user
   visibility: "private",
   user: [
      { id: 345, permission: "edit" },
      { id: 456, permission: "view" }
   ]
},
...
]

Card

[{
   id: 789,
   content: "Loorem ipsum dolor sit amet.",
   owner: 123, // reference to user
   board: 646 // reference to board
},
...
]

Since the number of cards can be high, the cards are updated frequently and can be moved from board to board, I think this normalized approach would be better to keep the update queries simple. The downside is of course that I need some queries to load all boards + cards for a user.

What do you think? Does my modeling make sense?
Are the references placed correctly or should e.g. the board have a list of card id’s instead of the card having the board id for reference?

Since I’m fairly new to MongoDB, any advice would be appreciated. Thanks in advance!

One important thing to know is that when a document is updated the whole document is written over. The exact reasons why eludes me but I suspect that concurrency and compression is easier this way.

For that, I try to make frequently updated documents small and refer to them rather than embed them. It is a trade off so your millage may vary.

For example, I would keep the current location of a user in a separate document rather than having it embedded in user document. The ratio of location update to location query is higher, so despite having slower read the overall efficiency is better.