MongoDB Data Modelling

MongoDB Data Modelling

Data has a versatile schema in MongoDB. Documents in an identical collection. They do not need to have the same set of fields or structure Common fields may contain different types of data in a collection's documents.

Data Model Design

Two types of data models are given by MongoDB: an embedded data model and a standardized data model. You can use one of the models when preparing your document, based on the requirements.

Embedded Data Model

You can (embed) all the relevant data into a single document in this model, which is also known as a de-normalized data model.

For example, suppose we get the employee information in three different documents, namely, Personal Details, Contact and Address, as shown below, you can embed all three documents in a single one.

{
	_id: ,
	Emp_ID: "10025AE336"
	Personal_details:{
		First_Name: "Radhika",
		Last_Name: "Sharma",
		Date_Of_Birth: "1995-09-26"
	},
	Contact: {
		e-mail: "radhika_sharma.123@gmail.com",
		phone: "9848022338"
	},
	Address: {
		city: "Hyderabad",
		Area: "Madapur",
		State: "Telangana"
	}
}

Normalized Data Model

In this model, using references, you can refer to the sub-documents in the original text. For example, in the normalised model, you can re-write the above document as:

Employee:

{
	_id: <ObjectId101>,
	Emp_ID: "10025AE336"
}

Personal_details:

{
	_id: <ObjectId102>,
	empDocID: " ObjectId101",
	First_Name: "Radhika",
	Last_Name: "Sharma",
	Date_Of_Birth: "1995-09-26"
}

Contact:

{
	_id: <ObjectId103>
	empDocID: " ObjectId101",
	e-mail: "radhika_sharma.123@gmail.com",
	phone: "9848022338"
}

Address:

{
	_id: <ObjectId104>
	empDocID: " ObjectId101",
	city: "Hyderabad",
	Area: "Madapur",
	State: "Telangana"
}

Considerations while designing Schema in MongoDB

• According to user needs, build your schema.
• If you use them together, combine the objects into one document. Separate them otherwise (but make sure there is no need for joins).
• Duplicate the data (but limited) because, relative to processing time, disk space is cheap.
• Do join in when write, not while read.
• Optimize the schema for most instances of frequent use.
• In the schema, do complex aggregation.

Example

For his blog / website, assume a client wants a database design and see the differences between the design of RDBMS and MongoDB schema. The following requirements refer to the website.

• The unique title, definition and url of any post.
• You may have one or more tags on each post.
• Each post has its publisher 's name and total number of likes.
• Each post, along with their name, message, data-time and likes, has comments provided by users.
• There may be zero or more comments on each post.

The design for the above requirements in the RDBMS schema will have a minimum of three tables.

While the design will have one collection post and the following structure in the MongoDB schema-

{
   _id: POST_ID
   title: TITLE_OF_POST, 
   description: POST_DESCRIPTION,
   by: POST_BY,
   url: URL_OF_POST,
   tags: [TAG1, TAG2, TAG3],
   likes: TOTAL_LIKES, 
   comments: [	
      {
         user:'COMMENT_BY',
         message: TEXT,
         dateCreated: DATE_TIME,
         like: LIKES 
      },
      {
         user:'COMMENT_BY',
         message: TEXT,
         dateCreated: DATE_TIME,
         like: LIKES
      }
   ]
}

So, you need to join three tables in RDBMS when showing the data, and in MongoDB, data will only be shown from one collection.