Ao projetar esquemas no Mongo DB, especialmente nas primeiras vezes, uma lista de verificação rápida e útil para escolher se deseja ou não usar documentos embutidos em uma relação um-para-muitos.
Então, aqui está a lista de verificação:
Tipo de consulta : pergunte-se qual poderia ser a melhor representação de modelo para as consultas mais frequentes que você precisará fazer. Sempre que obtiver o documento pai, sempre (ou muito frequentemente) precisarei de todos os documentos filho. Resposta: aninhada.
Ciclo de vida do modelo de dados : pense no ciclo de vida do documento contêiner e seu conteúdo: faz sentido que os documentos filho ainda terão que existir quando o documento pai for excluído? Se a resposta for “não” aninhada é o caminho.
Instantâneos : outro motivo que deve afetar sua escolha são os dados que você está representando e se o item aninhado é um instantâneo de algo que aconteceu em um determinado momento. Suponha que você esteja trabalhando com um objeto “Recibo” que contém uma lista de produtos comprados, que serão copiados como documentos aninhados no recibo. Você está armazenando uma informação relacionada a um tempo específico, como o custo do produto. Portanto, se seus documentos filho forem instantâneos, escolha uma representação aninhada.
Acesso direto : quantas vezes você precisa acessar facilmente o documento aninhado (sem se preocupar com seu contêiner). Se precisar, escolha um design plano com referências.
Número de objetos aninhados : um documento MongoDB tem um limite de tamanho de 16 MB (uma grande quantidade de dados). Se sua subcoleção puder crescer sem limites, ficará estagnada.
Regra prática: se a quantidade de dados a serem transferidos não afeta a experiência do seu cliente e o número de subdocumentos tem um limite numérico, vá aninhado, caso contrário, nivelado.
Obrigado a Gabriele Lana por compartilhar isso comigo 🙂