MongoDB - Modélisation des données

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

Conception de modèles de données

MongoDB fournit deux types de modèles de données: - Modèle de données intégré et modèle de données normalisé. En fonction des besoins, vous pouvez utiliser l'un ou l'autre des modèles lors de la préparation de votre document.

Modèle de données intégré

Dans ce modèle, vous pouvez avoir (incorporer) toutes les données associées dans un seul document, il est également connu sous le nom de modèle de données dénormalisé.

Par exemple, supposons que nous obtenions les détails des employés dans trois documents différents, à savoir, Personal_details, Contact et, Address, vous pouvez intégrer les trois documents dans un seul, comme indiqué ci-dessous -

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

Modèle de données normalisé

Dans ce modèle, vous pouvez faire référence aux sous-documents dans le document d'origine, à l'aide de références. Par exemple, vous pouvez réécrire le document ci-dessus dans le modèle normalisé comme:

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: "[email protected]",
	phone: "9848022338"
}

Address:

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

Considérations lors de la conception de schéma dans MongoDB

• Concevez votre schéma en fonction des besoins des utilisateurs.

• Combinez les objets en un seul document si vous les utiliserez ensemble. Sinon, séparez-les (mais assurez-vous qu'il ne devrait pas être nécessaire de jointures).

• Dupliquez les données (mais limité) car l'espace disque est bon marché par rapport au temps de calcul.

• Effectuez des jointures en écriture, pas en lecture.

• Optimisez votre schéma pour les cas d'utilisation les plus fréquents.

• Effectuez une agrégation complexe dans le schéma.

Exemple

Supposons qu'un client ait besoin d'une conception de base de données pour son blog / site Web et voit les différences entre la conception de schéma SGBDR et MongoDB. Le site Web a les exigences suivantes.

• Chaque message a un titre, une description et une URL uniques.

• Chaque message peut avoir une ou plusieurs balises.

• Chaque article porte le nom de son éditeur et le nombre total de likes.

• Chaque message contient des commentaires des utilisateurs avec leur nom, leur message, leur temps de données et leurs goûts.

• Sur chaque article, il peut y avoir zéro ou plusieurs commentaires.

Dans le schéma SGBDR, la conception des exigences ci-dessus comportera au minimum trois tables.

Dans le schéma MongoDB, la conception aura un article de collection 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
      }
   ]
}

Ainsi, lors de l'affichage des données, dans le SGBDR, vous devez joindre trois tables et dans MongoDB, les données ne seront affichées qu'à partir d'une seule collection.