Modellazione dei Dati MongoDB

I dati di MongoDB hanno uno schema flessibile schema.documents all'interno della stessa raccolta. I documenti nella stessa raccolta. Non è necessario che abbiano lo stesso set di campi o campi comuni nella struttura della raccolta, i documenti possono contenere dati di diversi tipi.

Progettazione del modello di dati

MongoDB offre due tipi di modelli di dati: modello di dati embedded e modello di dati normalizzato. In base alle esigenze, è possibile utilizzare uno dei due modelli durante la preparazione dei documenti.

Modello di dati incorporato

In questo modello, puoi mettere tutti i dati correlati (inseriti) in un documento, il che si chiama anche modello di dati non normalizzato.

Ad esempio, supponiamo che otteniamo i dettagli dell'impiegato in tre documenti diversi (Dettagli_personali, Contatto e Indirizzo). Puoi inserire tutti e tre i documenti in un documento, come indicato di seguito:

{
	_id:,
	Emp_ID: "10025AE336"
	Dettagli_personali:{
		Nome: "Radhika"
		Cognome: "Sharma"
		Data_Di_Nascita: "1995-09-26"
	}
	Contatto: {
		e-mail: "[email protected]"
		telefono: "9848022338"
	}
	Indirizzo: {
		città: "Hyderabad",
		Area: "Madapur",
		Stato: "Telangana"
	}
}

Modello di dati normalizzato

In questo modello, puoi usare riferimenti per fare riferimento ai sottodocumenti del documento originale. Ad esempio, puoi riscrivere il seguente documento come modello normalizzato:

Impiegato:

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

Dettagli_personali:

{
	_id: ObjectId102>
	empDocID: "ObjectId101"
	Nome: "Radhika"
	Cognome: "Sharma"
	Data_Di_Nascita: "1995-09-26"
}

Contatto:

{
	_id: ObjectId103>
	empDocID: "ObjectId101"
	e-mail: "[email protected]"
	telefono: "9848022338"
}

Indirizzo:

{
	_id: ObjectId104>
	empDocID: "ObjectId101"
	città: "Hyderabad",
	Area: "Madapur",
	Stato: "Telangana"
}

Considerazioni durante la progettazione della struttura in MongoDB

• Progetta la struttura in base alle richieste dell'utente.

• Se li si utilizza insieme, li si combinano in un documento. Altrimenti, li si separa (ma assicurati che non siano necessarie connessioni).

• Copia i dati (ma con limiti), perché lo spazio su disco è più economico rispetto al tempo di calcolo.

• Effettua le connessioni durante la scrittura, non durante la lettura.

• Ottimizza la tua soluzione per i casi d'uso più comuni.

• Esegui aggregazioni complesse nella struttura.

Esempio online

Supponiamo che il cliente debba progettare un database per il suo blog/sito web e vedere le differenze tra la progettazione del modello RDBMS e MongoDB. Il sito ha i seguenti requisiti.

• Ogni post ha un titolo unico, una descrizione e un URL.

• Ogni post può avere una o più etichette.

• Ogni post ha il nome del pubblicatore e il numero totale di mi piace.

• Ogni post ha commenti forniti dagli utenti, i loro nomi, messaggi, dati di tempo e mi piace.

• Su ogni post, possono esserci zero o più commenti.

Nell'architettura RDBMS, il design necessario per le richieste sopra elencate avrà almeno tre tabelle.

Nel modello MongoDB, il design avrà una collezione di帖子 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, quando si visualizzano i dati, in un RDBMS, è necessario connettere tre tabelle, mentre in MongoDB, i dati verranno visualizzati da una sola collezione.