CODEWITHSUNDEEP
mongodbdata-structuresnosqldata-modeling
Jason
Jason

Reputation: 73

Sub-structures vs Flat Data-Structure in MongoDB - NoSQL

I try to understand how to best structure a MongoDB Schema and therefore looking for guidance especially on using substructures (embedded documents) vs. a flat data structure.

Let's imagine we want to store a User account within MongoDB. The user has only one address, therefore we could choose one of the two following structures:

{ 
_id: String,
username: String,
firstname: String,
surname: String,
email: String,
street: String,
city String,
zip: Number,
}

or

{
_id: String,
name: {
    first: String,
    last: String,
    }
email: String,
address: {
    street: String,
    city String,
    zip: Number,
    }
}

What are the advantages / disadvantages of each of the structures. Is there a rule when to use substructures or when to use a flat structure? What is the reasoning for one against the other?

Thank you in advance!

Upvotes: 3

Views: 1202

Answers (1)

Jitendra
Jitendra

Reputation: 3185

There are various data modeling patterns and schema design provided in MongoDB.I will share my experience what problems I have faced and what are the benefits of different DB schema. We will discuss it one by one below:

  1. Embedded VS Flat data structure: In this case there is not much difference between both of the pattern but in case of data model in embedded form we are grouping similar kind of data so that makes your query little bit easy or small in size while you will $project data from any collection.

    For example: if you want to fetch complete address then in case of embedded doc you don't need to $project address fields individually and if you want to skip address field while fetching document then you do not need to skip address fields individually.

  2. Embedded (one to one) VS Embedded (one to many): As we discuss benefits of the embedded document on flat data structure but in case, if our users are having more then one addresses then we need to go for embedded documents with one to many relationship.
    The schema for defining one to one and one to many relationship is as below:

One To One Relation schema: 

{
_id: String,
name: {
    first: String,
    last: String,
    }
email: String,
address: {
    street: String,
    city String,
    zip: Number,
    }
}

One To Many Relationship schema: 

  {
    _id: String,
    name: {
        first: String,
        last: String,
        }
    email: String,
    address: [{           // Embedded address doc with one to many relationship
        street: String,
        city String,
        zip: Number,
      }]
  }

In case of one to one relationship it will not that much affect your query part but if you will go with one to many relationship there will be many conceptual changes in your query.

For example: As mainly we are facing different scenarios while updating both kinds of data structures so I will share the difference between update queries.

To update data embedded with one to one relationship you can simply use dot notation.

db.collection.update(
   { _id: 'anyId' },
   { $set: { "address.street": "abc" } }
)

To update data embedded with one to many relationship you need to use $ operator. In this one there are two different cases. First, if you want to update specific element of subdocument and second if you want to update all subdocuments:

Case 1 query will be (with the use of $ operator): 

  db.collection.update(
       { 'address.streent': 'abc' },
       { $set: { "address.$.street": "xyz" } }
  )

Case 2 query will be (with use of $[]):

  db.collection.update(
       { 'address.streent': 'abc' },
       { $set: { "address.$[]": "xyz" } }
  )

Upvotes: 1

Related Questions