O exemplo que você dá, em comum com a maioria dos exemplos do mundo real de relacionamentos muitos-para-muitos, é na verdade um exemplo de poucos-para-poucos relação. Você pode ter muitos restaurantes e muitos clientes, mas, em comparação com todo o conjunto, qualquer restaurante serviu apenas um pequeno subconjunto de clientes e a maioria dos clientes individuais visitará apenas um pequeno subconjunto dos restaurantes. Parece uma rede escassamente vinculada, onde a taxa de densidade do link está significativamente abaixo de um.

No entanto, você perguntou sobre muitos para muitos, então que tal usarmos uma rede neural como exemplo? As redes neurais geralmente formam redes densas e, portanto, representam uma verdadeira rede muitos-para-muitos. Nesse caso, a resposta é fácil - não use mongoDB. Use estruturas personalizadas e estratégias de serialização adaptadas aos seus requisitos específicos. Afinal, os verdadeiros relacionamentos muitos-para-muitos são quase sempre atípicos e, portanto, justificam um tratamento específico.

Com isso dito, modelando o mais usual poucos para poucos O relacionamento no mongoDB pode ser alcançado sem sacrificar a rica estrutura do documento, e como você consegue isso depende de seus padrões de acesso.

Assim, com o exemplo de rede de restaurante/diner, se você normalmente consulta um restaurante em seus clientes, você criaria uma matriz de diner_ids realizada com cada restaurante. A outra maneira significaria uma matriz de restaurant_ids realizada com cada restaurante. Ambos para capacidade de consulta bidirecional.

Deve-se tomar cuidado porque não há restrição de chave estrangeira no mongoDB e, portanto, manter a integridade referencial de seus dados é sua responsabilidade.

Se o desempenho for o mais importante para você, convém incorporar os dados em cada documento em vez de referenciá-los com um id. Esta é a opção de maior desempenho para leitura (não tanto para gravação), pois todos os dados podem ser retirados do disco em uma única batida. Isso significa que você precisará trabalhar mais ao atualizar os valores dos dados para garantir a integridade de seus dados, mas geralmente isso não é tão assustador quanto parece à primeira vista. Com que frequência os clientes realmente mudam de nome? E, dependendo do tamanho do documento, você pode não necessariamente querer incorporar o documento completo, um subconjunto dos dados mais um id para apontar para o registro completo muitas vezes fará o truque.

Em resumo, o design do esquema do mongoDB deve ser orientado pelos requisitos do aplicativo. Diferentes esquemas para diferentes aplicativos em oposição a um banco de dados relacional monolítico para governá-los todos. Qual é a realidade dos dados? Como o aplicativo realmente usa esses dados? Qual o tamanho dos objetos de documento que estão sendo armazenados? Responda a essas perguntas e seu esquema praticamente se projetará.