Modélisation des données MongoDB

Les données dans MongoDB ont un schéma flexible schema.documents dans le même ensemble. Les documents dans le même ensemble. Ils n'ont pas besoin d'avoir le même ensemble de champs ou des champs communs dans la structure de l'ensemble, les documents peuvent contenir différents types de données.

Data model design

MongoDB provides two types of data models: embedded data model and normalized data model. According to the needs, you can use either of the 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 non-normalized data model.

For example, suppose we obtain employee details from three different documents (Personal_details, Contact, and Address). Then, all three documents can be embedded 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 the architecture in MongoDB

• Design the architecture according to user requirements.

• If they are used together, combine them into a document. Otherwise, keep them separate (but make sure you do not need to connect).

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

• Join at write time, not at read time.

• Optimize your solution for the most common use cases.

• Perform complex aggregations in the architecture.

Online examples

Assuming the customer needs to set up a blog for/The website designs the 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 the publisher and the total number of likes.

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

• Pour chaque message, il peut y avoir zéro ou plusieurs commentaires.

Dans l'architecture RDBMS, la conception nécessaire pour les exigences ci-dessus aura au moins trois tables.

Dans le schéma MongoDB, la conception aura une collection de messages et la structure suivante-

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

Par conséquent, lors de l'affichage des données, dans le RDBMS, vous devez connecter trois tables, tandis que dans MongoDB, les données seront affichées à partir d'une seule collection.