MongoDB Data Model

MongoDB has a flexible schema. Unlike other relational database, it doesn't require to declare and create a table/collection schema. MongoDB's collection don't enforce document structure. The main challenge in data modeling is balancing the application needs, database engine performance , and the data fetching patterns. While designing data models, always consider the data usage (i.e. queries, updates, and processing of the data) and the data structure.

Embedded Data Model:

In MongoDB, we can embed the related data in a single document. This is known as denormalized model. In general it will provide better performance for read. You can retrieve all the related information on a single database call. Embedded data model also update related data in a single atomic write operation.

Example:

{
    _id: ObjectId("52e972f2ce37a8d413f54100")
    , start: {
        _id: "52e79f893764e832354f937e"
       , name: "Cuttack"
       , pin: "789809"
    }
    , destination: {
        _id: "52e79f893764e832354f937f"
       , name: "Bhubaneswar"
       , pin: "751010"
    }
}

Pro:

  1. It will provide better performance for read operation.

  2. Data will be updated in atomic write operation.

Con:

  1. Data redundancy

  2. Need to take care the embedded document size (more the size will reduce performance)

Normalised Data Model:

Normalized data model are the same as relational tables having relationship between different tables. It will be more helpful for more hierarchical data sets. It will reduce the data redundancy. It requires more round trip to the server.

Example:

{
     _id: ObjectId("52e972f2ce37a8d413f54100")
    , start_id: ObjectId("52e79f893764e832354f937e")
    , destination_id: ObjectId("52e79f893764e832354f937f")
}
[
     {
        _id: ObjectId("52e79f893764e832354f937e")
       , name: "Cuttack"
       , pin: "789809"
    }
    , {
        _id: ObjectId("52e79f893764e832354f937f")
       , name: "Bhubaneswar"
       , pin: "751010"
    }
]

Pro:

  1. It will minimize data redundancy

Con:

  1. It requires more round trip to the server to get the required data.

  2. Data write is not atomic.

While designing data model on MongoDB it always depends on the data and how frequent you retrieve the data. Lets check the below example.

{
     _id: ObjectId("52e9da0262e381f019c6275a")
    ,  name: "Srikant Biswal"
    , phone: "011-2346789"
    , email: "srikant@email.com"
}

{
     _id: ObjectId("513d9e794ddecb1cf0917f26")
    , user_id: ObjectId("52e9da0262e381f019c6275a")
    , street: "123 Test"
    , city: "Bhubaneswar"
    , state: "Odisha"
    , pin: "751010"
}

If you are frequently retrieve the address along with the user document, it is better data model would be embedded data model as following.

{
     _id: ObjectId("52e9da0262e381f019c6275a")
    ,  name: "Srikant Biswal"
    , phone: "011-2346789"
    , email: "srikant@email.com"
    , address: {
        , street: "123 Test"
        , city: "Bhubaneswar"
        , state: "Odisha"
        , pin: "751010"
     }
}

Conclusion:

In this tutorial, I have explained the basics of data model and design on MongoDB. I will add more in my next article.

Reference:

http://docs.mongodb.org/

Discussion
6 - 1 =
** To prevent abusing comments from publishing, posted comments will be reviewed and then published!
 Srikant Biswal

More from me...
Auto Increment in MongoDB
about 3 years ago 2413 Views
MongoDB Restore
about 3 years ago 1707 Views
MongoDB Backup
about 3 years ago 1536 Views
MongoDB Read
about 4 years ago 1572 Views
Mongo DB crud operation
about 4 years ago 1864 Views