I have a general DB related question. It's more specific to how collections are handled with respect to MongoDB.

Let's say I have a Parent collection. I then have some Child collection that is apart of Parent. They each have separate schemas. Currently, they're existing as separate collections in the DB though.

I'm handling the linking by adding the parentId property to every Child document.

I.e.

Some_Child = {
        "parentId" : "some_id",
         rest_of_schema
  } 

This seems to work just fine. However, I'm noticing I now have to work with two collections everytime I want Child data. This can lead to more code. I.e. Multiple subscriptions, and DB calls for everytime I just want to do something with Child.

What are some thoughts on structuring the data this way vs. just having an array of Childs on each Parent document?

I.E.

 Some_Parent = {
        "Childs" : [
                         {child1},
                         {child2},
                         {childN}
],
        Rest_Of_Schema
       }

My concern with this is about it being future-proof. Say if a lot more data and functionality is needed for Child...then Parent documents could end up being really large and messy. Also, it might just be cleaner to abstract away these two Collections in general.

Normally, (in a RDMS), I wouldn't of even thought about using option #2. So I'm just wondering if this is an accepted pattern with document stores, MongoDB (and just general non-relational DBMS).

Any insights?

I have a general DB related question. It's more specific to how collections are handled with respect to MongoDB.

Let's say I have a Parent collection. I then have some Child collection that is apart of Parent. They each have separate schemas. Currently, they're existing as separate collections in the DB though.

I'm handling the linking by adding the parentId property to every Child document.

I.e.

Some_Child = {
        "parentId" : "some_id",
         rest_of_schema
  } 

This seems to work just fine. However, I'm noticing I now have to work with two collections everytime I want Child data. This can lead to more code. I.e. Multiple subscriptions, and DB calls for everytime I just want to do something with Child.

What are some thoughts on structuring the data this way vs. just having an array of Childs on each Parent document?

I.E.

 Some_Parent = {
        "Childs" : [
                         {child1},
                         {child2},
                         {childN}
],
        Rest_Of_Schema
       }

My concern with this is about it being future-proof. Say if a lot more data and functionality is needed for Child...then Parent documents could end up being really large and messy. Also, it might just be cleaner to abstract away these two Collections in general.

Normally, (in a RDMS), I wouldn't of even thought about using option #2. So I'm just wondering if this is an accepted pattern with document stores, MongoDB (and just general non-relational DBMS).

Any insights?

• javascript
• database
• mongodb
• non-relational-database

1 Answer 1

You can definitely use Option #2 as long as the number of children for each parent is guaranteed to not be high, as you do not want to risk reaching the 16MB document size limit.

In Mongo, the one-to-many relationship could be split into three different implementations (each have pros and cons):

1. one-to-a-few: embedding the child documents within the parent is probably the best approach.
2. one-to-many: keep a list of the IDs of the child documents in an array of the parent. Works when the number of linked documents is large but not exceedingly large.
3. one-to-millions: keep the parent ID in the child documents. This works for any number of child documents.

Which one to use depends on many factors, like what is the most likely way of navigating the relationship, whether you need to lookup child documents independently from the parent, etc.