Puoi progettare uno schema in cui puoi fare riferimento o incorporare documenti. Diamo un'occhiata alla prima opzione dei documenti incorporati. Con l'applicazione sopra, potresti memorizzare le informazioni in un documento come segue:
// db.table1 schema
{
"_id": 3, // table1_id
"is_active": true,
"created": ISODate("2015-04-07T16:00:30.798Z"),
"lang": [
{
"name": "foo",
"surname": "bar",
"address": "xxx"
},
{
"name": "abc",
"surname": "def",
"address": "xyz"
}
]
}
Nello schema di esempio sopra, avresti essenzialmente incorporato il table1_lang informazioni all'interno della table1 principale documento. Questo design ha i suoi pregi, uno dei quali è la località dei dati. Poiché MongoDB archivia i dati in modo contiguo sul disco, mettere tutti i dati necessari in un documento assicura che i dischi rotanti impiegheranno meno tempo per cercare una posizione particolare sul disco. Se la tua applicazione accede frequentemente a table1 informazioni insieme a table1_lang dati quindi quasi sicuramente vorrai seguire il percorso incorporato. L'altro vantaggio dei documenti incorporati è l'atomicità e l'isolamento nella scrittura dei dati. Per illustrare questo, supponiamo di voler rimuovere un documento che ha una chiave lang "name" con valore "foo", questo può essere fatto con una singola operazione (atomica):
db.table.remove({"lang.name": "foo"});
Per maggiori dettagli sulla modellazione dei dati in MongoDB, leggere i documenti Introduzione alla modellazione dei dati , in particolare Modello Relazioni uno-a-molti con documenti incorporati
L'altra opzione di progettazione è fare riferimento a documenti in cui si segue uno schema normalizzato. Ad esempio:
// db.table1 schema
{
"_id": 3
"is_active": true
"created": ISODate("2015-04-07T16:00:30.798Z")
}
// db.table1_lang schema
/*
1
*/
{
"_id": 1,
"table1_id": 3,
"name": "foo",
"surname": "bar",
"address": "xxx"
}
/*
2
*/
{
"_id": 2,
"table1_id": 3,
"name": "abc",
"surname": "def",
"address": "xyz"
}
L'approccio di cui sopra offre una maggiore flessibilità nell'esecuzione delle query. Ad esempio, per recuperare tutti i table1_lang figlio documenti per l'entità padre principale table1 con id 3 sarà semplice, crea semplicemente una query sulla raccolta table1_lang :
db.table1_lang.find({"table1_id": 3});
Lo schema sopra normalizzato che utilizza l'approccio di riferimento del documento presenta anche un vantaggio quando si hanno relazioni uno-a-molti con un'arietà molto imprevedibile. Se hai centinaia o migliaia di table_lang documenti per dare table entità, l'incorporamento ha così tante battute d'arresto per quanto riguarda i vincoli spaziali perché più grande è il documento, più RAM utilizza e i documenti MongoDB hanno un limite di dimensioni rigide di 16 MB.
La regola generale è che se il modello di query dell'applicazione è noto e si tende ad accedere ai dati solo in un modo, un approccio integrato funziona bene. Se la tua applicazione esegue query sui dati in molti modi o non sei in grado di anticipare i modelli di query dei dati, in questo caso sarà appropriato un modello di riferimento ai documenti più normalizzato.
Rif:
