MongoDB
 sql >> Base de Dados >  >> NoSQL >> MongoDB

editando subdocments relacionamento N-N no mongodb


Com base nas informações que você forneceu, eu recomendaria duas abordagens possíveis, partindo da mesma base:

Eu recomendaria essa abordagem se:
  • Você tem uma alta cardinalidade tanto de documentos de artigos quanto de plataformas

  • Você deseja poder gerenciar ambas as entidades de forma independente, ao mesmo tempo em que sincroniza referências entre elas
    // articles collection schema
    {
    "_id": ...,
    "title": "I am an article",
    
    ...
    
    "platforms": [ "platform_1", "platform_2", "platform_3" ],
    ...
    }
    
    
    // platforms collection schema    
    {
    "_id": "platform_1",
    "name": "Platform 1",
    "url": "http://right/here",
    ...
    },
    
    {
    "_id": "platform_2",
    "name": "Platform 2",
    "url": "http://right/here",
    ...
    },
    
    {
    "_id": "platform_3",
    "name": "Platform 3",
    "url": "http://right/here",
    ...
    }
    

Mesmo que essa abordagem seja bastante flexível, ela tem um custo - se você precisar de dados do artigo e da plataforma, precisará disparar mais consultas para sua instância do MongoDB, pois os dados são divididos em duas coleções diferentes.

Por exemplo, ao carregar uma página de artigo, considerando que você também deseja exibir uma lista de platforms , você teria que disparar uma consulta para a articles collection , e também acionar uma pesquisa na platforms collection para recuperar todas as entidades da plataforma nas quais esse artigo foi publicado por meio dos membros da platform s no article document .

No entanto, se você tiver apenas um pequeno subconjunto de platform attributes acessados ​​com frequência que você precisa ter disponível ao carregar um article document , você pode aprimorar as platforms array na articles collection para armazenar esses atributos além do _id referência aos documentos da plataforma:
// enhanced articles collection schema  
{
"_id": ...,
"title": "I am an article",

...

"platforms": [
    {platform_id: "platform_1", name: "Platform 1"},
    {platform_id: "platform_2", name: "Platform 2"},
    {platform_id: "platform_3", name: "Platform 3"}
],

...

}

Essa abordagem híbrida seria adequada se os platform data attributes que você recupera com frequência para exibir junto com dados específicos do artigo não estão mudando com tanta frequência.

Caso contrário, você terá que sincronizar todas as atualizações feitas nos platform document attributes na platforms collection com o subconjunto de atributos que você rastreia como parte da matriz de plataformas para documentos de artigos.

Em relação ao gerenciamento de listas de artigos para plataformas individuais, não recomendaria armazenar referências N-para-N em ambas as coleções, pois o mecanismo mencionado já permite extrair listas de artigos consultando a articles collection usando uma consulta de localização com o _id valor do platform document :
Approach #1
db.articles.find({"platforms": "platform_1"});

Approach #2:
db.articles.find({"platforms.platform_id": "platform_1"});

Tendo apresentado duas abordagens diferentes, o que eu recomendaria agora é que você analise os padrões de consulta e os limites de desempenho de seu aplicativo e tome uma decisão calculada com base nos cenários encontrados.