Seu desafio vem do fato de que Prop_Info deve ser recuperado por ambas as consultas. Isso torna difícil descobrir em qual coleção Mongo ele deve viver.

No MongoDB, você cria seu esquema de documento com o objetivo ideal de que um único documento tenha todas as informações necessárias de acordo com seus padrões de consulta. No caso de você precisar ter os mesmos dados D (como Prop_Info no seu caso) retornado por duas consultas separadas em duas coleções separadas A e B , você deve escolher entre as três estratégias a seguir:

1. 
   Duplicar D nos documentos de ambos A e B e imponha consistência com seu código. Normalmente, essa é a escolha de design de sistemas de alto desempenho que desejam eliminar a necessidade de uma segunda consulta, mesmo que isso tenha o custo de complexidade de código adicional no lado da inserção/atualização e com alguns possíveis problemas de consistência, pois o Mongo não é ACID.
   
2. 
   Coloque D em A e armazene uma referência (DBRef ou alguma outra combinação de campos de identificação) em B para que você possa acessá-lo com uma segunda consulta. Esta é normalmente a escolha de design quando o número de consultas para A excede o número de consultas para B . Ele mantém D local para a coleção consultada com mais frequência. Neste padrão de design de esquema, você só precisa fazer uma segunda consulta ao consultar B .
   
3. 
   Coloque D em uma nova coleção C e faça uma segunda consulta a ele de A e B . Normalmente, essa é a escolha de design diante de requisitos futuros muito incertos, nos quais não está claro quais seriam as compensações se você optar por (1) ou (2) acima. É o esquema mais "relacional" e aquele que o forçará a fazer uma segunda consulta quando você consultar tanto A e B .
   

A estratégia escolhida depende do seu domínio, dos padrões de consulta, do suporte que você obtém de sua estrutura de mapeamento relacional de objeto (ORM) (se você usar uma) e, por último, mas não menos importante, de sua preferência.

Nas situações que encontrei, nunca escolhi (3). Eu usei (1) em situações de alto desempenho (sistemas analíticos). Eu usei (2) em todos os outros lugares desde que os padrões de acesso de consulta tornaram óbvio onde os dados "compartilhados" deveriam residir.

Depois de escolher sua estratégia, se você ainda precisar de ajuda, poste outra pergunta SO que se concentre especificamente no problema de design do esquema de acordo com a estratégia escolhida.

Três dicas finais:

1. 
   Se os dados compartilhados D tem uma multiplicidade de relacionamento maior que 1 use um array. Você pode indexar arrays inteiros e consultar precisamente dentro de arrays usando $elemMatch .
   
2. 
   Para atualizar D na estratégia (1) ou (2) use o modificador atômico do MongoDB operações , muitos dos quais são projetados para operar em matrizes.
   
3. 
   Esta pergunta SO cobre o padrão de duas consultas DBRef na resposta de @Stennie. (@Stennie funciona para 10gen, os marcadores do MongoDB.)
   

Boa sorte!