MongoDB Data Modeling

MongoDB's data in the same collection has a flexible schema schema.documents. Documents in the same collection. They do not need to have the same field set or common fields in the structure of the collection, documents may contain different types of data.

Data model design

MongoDB provides two types of data models: embedded data model and normalized data model. Depending on the requirements, you can use either of these two models when preparing documents.

Embedded data model

In this model, you can put all related data (embedded) in a single document, which is also known as a denormalized data model.

For example, assuming we obtain employee details from three different documents (Personal_details, Contact, and Address), we can embed all three documents into a single document as follows:

{
	_id:,
	Emp_ID: ""10025AE336"
	Personal_details: {
		First_Name: "Radhika",
		Last_Name: "Sharma",
		Date_Of_Birth: ""1995-09-26"
	}
	Contact: {
		e-mail: "[email protected]"
		phone: "9848022338"
	}
	Address: {
		city: "Hyderabad",
		Area: "Madapur",
		State: "Telangana"
	}
}

Normalized data model

In this model, you can use references to refer to sub-documents in the original document. For example, you can rewrite the following document as a normalized model:

Employee:

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

Personal_details:

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

Contact:

{
	_id: ObjectId103>,
	empDocID: "ObjectId"101"
	e-mail: "[email protected]"
	phone: "9848022338"
}

Address:

{
	_id: ObjectId104>,
	empDocID: "ObjectId"101"
	city: "Hyderabad",
	Area: "Madapur",
	State: "Telangana"
}

Considerations when designing architecture in MongoDB

• Design the architecture according to user requirements.

• If they are used together, combine them into a single document. Otherwise, keep them separate (but make sure no connection is needed).

• Replicate data (with limitations), as disk space is cheaper than computing time.

• Join at the time of writing, rather than at the time of reading.

• Optimize your solution for the most common use cases.

• Perform complex aggregations in the architecture.

Online examples

Assuming the customer needs to have a blog for/The website designs a database and examines the differences between RDBMS and MongoDB schema design. The website has the following requirements.

• Each post has a unique title, description, and URL.

• Each post can have one or more tags.

• Each post has the name of its publisher and the total number of likes.

• Each post has comments provided by users, as well as their names, messages, data time, and likes.

• On each post, there can be zero or more comments.

In the RDBMS architecture, the design used for the above requirements will have at least three tables.

In the MongoDB schema, the design will have a post collection and the following structure-

{
　　　_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
　　　　　　}
　　　}
}

Therefore, when displaying data, in RDBMS, you need to connect three tables, while in MongoDB, data will be displayed from a single collection.