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.