População de mangusto vs aninhamento de objetos

{ 
    "_id": ObjectId("5392fea00ff066b7d533a765"),
    "customerName": "Bill",
    "items": [
        ObjectId("5392fee10ff066b7d533a766"),
        ObjectId("5392fefe0ff066b7d533a767")
    ]
}

{ "_id": ObjectId("5392fee10ff066b7d533a766"), "prod": "ABC", "qty": 1 }
{ "_id": ObjectId("5392fefe0ff066b7d533a767"), "prod": "XYZ", "qty": 2 }

var order = db.orders.findOne({ "_id": ObjectId("5392fea00ff066b7d533a765") });
order.items = db.items.find({ "_id": { "$in": order.items } ).toArray();

{ 
    "_id": ObjectId("5392fea00ff066b7d533a765"),
    "customerName": "Bill",
    "items": [
        { "_id": ObjectId("5392fee10ff066b7d533a766"), "prod": "ABC", "qty": 1 },
        { "_id": ObjectId("5392fefe0ff066b7d533a767"), "prod": "XYZ", "qty": 2 }
    ]
}

db.orders.findOne({ "_id": ObjectId("5392fea00ff066b7d533a765") });

Incorporação

• 
  O tamanho total do documento com dados incorporados normalmente não excederá 16 MB de armazenamento (o limite BSON) ou caso contrário (como diretriz) terá matrizes que contêm 500 ou mais entradas.
  
• 
  Os dados incorporados geralmente não requerem alterações frequentes. Portanto, você pode conviver com a "duplicação" que vem da desnormalização, não resultando na necessidade de atualizar essas "duplicações" com as mesmas informações em muitos documentos pai apenas para invocar uma alteração.
  
• 
  Dados relacionados são frequentemente usados ​​em associação com o pai. O que significa que, se seus casos de "leitura/gravação" estiverem sempre precisando "ler/gravar" para pai e filho, faz sentido incorporar os dados para operações atômicas.
  

Referência

• 
  Os dados relacionados sempre excederão o limite BSON de 16 MB. Você sempre pode considerar uma abordagem híbrida de "bucketing", mas o limite rígido geral do documento principal não pode ser violado. Casos comuns são "postar" e "comentários" em que se espera que a atividade de "comentários" seja muito grande.
  
• 
  Os dados relacionados precisam de atualização regular. Ou essencialmente o caso em que você "normaliza" porque esses dados são "compartilhados" entre muitos pais e os dados "relacionados" são alterados com frequência suficiente para que seja impraticável atualizar itens incorporados em cada "pai" em que esse item "filho" ocorre . O caso mais fácil é apenas referenciar o "filho" e fazer a alteração uma vez.
  
• 
  Há uma separação clara de leituras e gravações. No caso de talvez você nem sempre exigir essa informação "relacionada" ao ler o "pai" ou de não precisar alterar sempre o "pai" ao escrever para a criança, pode haver uma boa razão para separar o modelo conforme referenciado. Além disso, se houver um desejo geral de atualizar muitos "subdocumentos" de uma só vez, nos quais esses "subdocumentos" são na verdade referências a outra coleção, muitas vezes a implementação é mais eficiente quando os dados estão em um arquivo separado. coleção.
  

1. Observe que, como isso foi originalmente escrito, o MongoDB introduziu o $lookup operador que de fato realiza "junções" entre coleções no servidor. Para os propósitos da discussão geral aqui, é "melhor" na maioria das circunstâncias que a sobrecarga de "consulta múltipla" incorrida por populate() e "várias consultas" em geral, ainda há uma "sobrecarga significativa" incorridos com qualquer $lookup operação.

O princípio de design central é "incorporado" significa "já está lá" em oposição a "buscar de outro lugar". Essencialmente, a diferença entre "no seu bolso" e "na prateleira", e em termos de E/S geralmente mais como "na prateleira da biblioteca no centro" , e notavelmente mais distante para solicitações baseadas em rede.