Puede diseñar un esquema en el que pueda hacer referencia o incrustar documentos. Veamos la primera opción de documentos incrustados. Con su aplicación anterior, puede almacenar la información en un documento de la siguiente manera:
// 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"
}
]
}
En el esquema de ejemplo anterior, esencialmente habría incrustado el table1_lang información dentro de la table1 principal documento. Este diseño tiene sus méritos, uno de ellos es la localidad de datos. Dado que MongoDB almacena datos de forma contigua en el disco, poner todos los datos que necesita en un documento garantiza que los discos giratorios tardarán menos tiempo en buscar una ubicación particular en el disco. Si su aplicación accede con frecuencia a table1 información junto con el table1_lang data, entonces seguramente querrá seguir la ruta incrustada. La otra ventaja de los documentos incrustados es la atomicidad y el aislamiento en la escritura de datos. Para ilustrar esto, digamos que desea eliminar un documento que tiene una clave lang "nombre" con valor "foo", esto se puede hacer con una sola operación (atómica):
db.table.remove({"lang.name": "foo"});
Para obtener más detalles sobre el modelado de datos en MongoDB, lea los documentos Introducción al modelado de datos , específicamente Model Relaciones de uno a varios con documentos incrustados
La otra opción de diseño es hacer referencia a documentos en los que sigue un esquema normalizado. Por ejemplo:
// 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"
}
El enfoque anterior brinda una mayor flexibilidad en la realización de consultas. Por ejemplo, para recuperar todos los hijos table1_lang documentos para la entidad matriz principal table1 con id 3 será sencillo, simplemente cree una consulta contra la colección table1_lang :
db.table1_lang.find({"table1_id": 3});
El esquema normalizado anterior que usa el enfoque de referencia de documentos también tiene una ventaja cuando tiene relaciones de uno a muchos con una aridad muy impredecible. Si tiene cientos o miles de table_lang documentos por dar table entidad, la incrustación tiene tantos contratiempos en lo que respecta a las limitaciones de espacio porque cuanto más grande es el documento, más RAM usa y los documentos de MongoDB tienen un límite de tamaño estricto de 16 MB.
La regla general es que si el patrón de consulta de su aplicación es bien conocido y se tiende a acceder a los datos de una sola manera, un enfoque integrado funciona bien. Si su aplicación consulta datos de muchas maneras o no puede anticipar los patrones de consulta de datos, un modelo de referencia de documentos más normalizado será apropiado para tal caso.
Referencia:
