Você pode criar um esquema no qual possa fazer referência ou incorporar documentos. Vejamos a primeira opção de documentos incorporados. Com o aplicativo acima, você pode armazenar as informações em um documento da seguinte forma:
// 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"
}
]
}
No esquema de exemplo acima, você basicamente teria incorporado o
table1_lang informações na table1 principal documento. Este design tem seus méritos, sendo um deles a localidade dos dados. Como o MongoDB armazena dados de forma contígua no disco, colocar todos os dados necessários em um documento garante que os discos giratórios demorem menos tempo para procurar um local específico no disco. Se seu aplicativo acessa com frequência table1 informações junto com o table1_lang dados, então você quase certamente desejará seguir a rota incorporada. A outra vantagem com documentos embutidos é a atomicidade e isolamento na escrita de dados. Para ilustrar isso, digamos que você queira remover um documento que tenha uma chave lang "name" com o valor "foo", isso pode ser feito com uma única operação (atômica):db.table.remove({"lang.name": "foo"});
Para obter mais detalhes sobre modelagem de dados no MongoDB, leia os documentos Introdução à modelagem de dados , especificamente Modelo Relacionamentos um-para-muitos com documentos incorporados
A outra opção de design é fazer referência a documentos nos quais você segue um esquema normalizado. Por exemplo:
// 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"
}
A abordagem acima oferece maior flexibilidade na execução de consultas. Por exemplo, para recuperar todos os
table1_lang filhos documentos para a entidade pai principal table1 com id 3 será simples, basta criar uma consulta na coleção table1_lang :db.table1_lang.find({"table1_id": 3});
O esquema normalizado acima usando a abordagem de referência de documento também tem uma vantagem quando você tem relacionamentos um-para-muitos com aridade muito imprevisível. Se você tiver centenas ou milhares de
table_lang documentos por table fornecido entidade, a incorporação tem muitos contratempos no que diz respeito às restrições espaciais porque quanto maior o documento, mais RAM ele usa e os documentos do MongoDB têm um limite de tamanho rígido de 16 MB. A regra geral é que, se o padrão de consulta do seu aplicativo for bem conhecido e os dados tenderem a ser acessados apenas de uma maneira, uma abordagem incorporada funcionará bem. Se seu aplicativo consultar dados de várias maneiras ou você não conseguir antecipar os padrões de consulta de dados, um modelo de referência de documento mais normalizado será apropriado para esse caso.
Ref.:
Padrões de projeto aplicados MongoDB:casos de uso práticos com o banco de dados NoSQL líder de Rick Copeland
