MongoDB - Modellazione dei dati

I dati in MongoDB hanno uno schema.documents flessibile nella stessa raccolta. Non è necessario che abbiano lo stesso insieme di campi o struttura I campi comuni nei documenti di una raccolta possono contenere diversi tipi di dati.

Progettazione del modello di dati

MongoDB fornisce due tipi di modelli di dati: - Modello di dati incorporato e modello di dati normalizzato. In base al requisito, è possibile utilizzare uno dei modelli durante la preparazione del documento.

Modello di dati incorporato

In questo modello, puoi avere (incorporare) tutti i dati correlati in un unico documento, è anche noto come modello dati denormalizzato.

Ad esempio, supponiamo di ottenere i dettagli dei dipendenti in tre diversi documenti, ovvero Dettagli_personali, Contatto e Indirizzo, puoi incorporare tutti e tre i documenti in uno solo come mostrato di seguito:

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

Modello di dati normalizzato

In questo modello, puoi fare riferimento ai documenti secondari nel documento originale, utilizzando i riferimenti. Ad esempio, è possibile riscrivere il documento sopra nel modello normalizzato come:

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

Considerazioni durante la progettazione dello schema in MongoDB

  • Progetta il tuo schema in base ai requisiti dell'utente.

  • Combina gli oggetti in un documento se li utilizzerai insieme. Altrimenti separali (ma assicurati che non ci sia bisogno di join).

  • Duplica i dati (ma limitato) perché lo spazio su disco è economico rispetto al tempo di calcolo.

  • Effettua unioni durante la scrittura, non durante la lettura.

  • Ottimizza il tuo schema per i casi d'uso più frequenti.

  • Esegui aggregazioni complesse nello schema.

Esempio

Supponiamo che un cliente abbia bisogno di un progetto di database per il suo blog / sito web e veda le differenze tra il design dello schema RDBMS e MongoDB. Il sito web ha i seguenti requisiti.

  • Ogni post ha il titolo, la descrizione e l'URL univoci.

  • Ogni post può avere uno o più tag.

  • Ogni post ha il nome del suo editore e il numero totale di Mi piace.

  • Ogni post ha commenti forniti dagli utenti insieme al loro nome, messaggio, data-time e Mi piace.

  • In ogni post possono esserci zero o più commenti.

Nello schema RDBMS, la progettazione per i requisiti di cui sopra avrà un minimo di tre tabelle.

Mentre si trova nello schema MongoDB, il design avrà un post di raccolta e la seguente struttura:

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

Quindi, mentre mostri i dati, in RDBMS devi unire tre tabelle e in MongoDB, i dati verranno mostrati da una sola raccolta.