MongoDB-多对多关系? [英] MongoDB - Many-to-many relationship?

问题描述

我很好奇一个人如何构建一个MongoDB，其中您拥有多对多的关系，并可能有成千上万的记录.

I'm curious how one would structure a MongoDB where you have many-to-many relationships, with potentially tens of thousands of records.

比方说，您有一个餐馆数据库，该数据库跟踪大量餐馆以及所有已签到这些餐馆的人.因此，用户可能想要查找一个人并查看他们已签到的所有餐厅，还希望查找餐厅并查看所有已签到的人员.

Let's say you have a restaurant database that tracks a huge array of restaurants and all the people who have checked into those restaurants. So the user may want to look up a person and see all the restaurants they've checked into, but also look up a restaurant and see all the people who have checked in.

如何以一种合理且易于搜索和更新的方式来构造这种结构?

How does one structure this in a way that makes sense and is easy to search and update?

推荐答案

您给出的示例与大多数现实世界中多对多关系示例相同，实际上是很少示例的示例-很少关系.您可能有许多餐厅和许多用餐者，但与整个餐厅相比，任何给定的餐厅仅服务一小部分用餐者，而大多数个人用餐者只会光顾一小部分餐馆.听起来像一个稀疏链接的网络，其中的链接密度比明显低于1.

The example you give, in common with most real-world examples of many-to-many relationships, is actually an example of a few-to-few relationship. You may have many restaurants and many diners but, compared to the entire set, any given restaurant has only served a small subset of diners and most individual diners will only have visited a small subset of the restaurants. It sounds like a sparsely linked network where the link density ratio is significantly below one.

要测量网络的链路密度(边缘密度)，我们计算 现有链接数与可能链接总数之比. 对于N个节点的网络，网络链路密度为D = m/ 0.5 * N *(N-1)完全连接的网络的(最大)链路密度D为1.-

To measure the link density (edge density) of a network, we calculate the ratio of existing links m to the total number of possible links. For a network of N nodes, the network link density is D = m / 0.5*N*(N-1) The (maximal) link density D of a completely connected network is 1. - Network-Science

但是，您问了很多对很多问题，那么我们以神经网络为例呢?神经网络通常形成密集的网络，因此代表了一个真正的多对多网络.在这种情况下，答案很简单-不要使用mongoDB.使用根据您的特定要求量身定制的自定义结构和序列化策略.毕竟，真正的多对多关系几乎总是离群的，因此有理由进行特定的对待.

However, you asked about many-to-many so how about we use a neural network as the example? Neural networks often form dense networks and so represent a true many-to-many network. In which case the answer is easy - don't use mongoDB. Use custom structures and serialisation strategies tailored to your specific requirements. After all, true many-to-many relationships are nearly always outliers and so justify specific treatment.

话虽如此，在不牺牲丰富文档结构的情况下，可以在mongoDB中建立更常见的 few-to-few 关系模型，而如何实现这取决于您的访问模式.

With that said, modelling the more usual few-to-few relationship in mongoDB can be achieved without sacrificing the rich document structure, and how you achieve this depends on your access patterns.

因此，以餐厅/餐厅网络示例为例，如果您通常要查询餐厅的餐厅，则您将创建每个餐厅持有的diner_id数组.另一种方式将意味着每位晚餐都拥有一个restaurant_id数组.两者都具有双向查询功能.

So, with the restaurant / diner network example, if you are typically going to query a restaurant on its diners then you would create an array of diner_ids held with each restaurant. The other way would mean an array of restaurant_ids held with each diner. Both for for two-way query ability.

必须小心，因为mongoDB中没有Foreign_key约束，因此维护数据的参照完整性是您的责任.

Care has to be taken because there is no foreign_key constraint in mongoDB and therefore maintaining your data's referential integrity is your responsibility.

如果性能对您来说最重要，那么您可能希望将数据嵌入每个文档中，而不要使用ID进行引用.这是用于读取的较高性能的选项(对于写入而言则不是那么多)，因为所有数据都可以在一次命中中从磁盘中拉出.这意味着在更新数据值以确保数据完整性时，您将需要做更多的工作，但是通常这并不像初看起来的那样令人恐惧.食客真正多久更改一次姓名?而且，根据文档的大小，您可能不一定要嵌入完整的文档，数据的子集以及指向完整记录的ID通常可以解决问题.

If performance is most important to you then you may wish to embed the data in each document rather than reference it with an id. This is the higher performance option for reading (not so much for writing) as all the data can be pulled off the disk in one hit. It means that you will need to do more work when you update data values to ensure the integrity of your data, but often this is not as scary as it first seems. How often do the diners really change their names? And depending on the document sizes, you may not necessarily want to embed the full document, a subset of the data plus an id to point to the full record will often do the trick.

简而言之，mongoDB模式设计应由应用程序需求驱动.针对一个应用程序使用不同的模式，而不是一个整体的关系数据库来统治它们.数据的真实性是什么?应用程序实际上是如何使用这些数据的?存储的文档对象有多大?回答这些问题，您的架构就会实际进行设计.

In short, mongoDB schema design should be driven by the application requirements. Different schemas for different applications as opposed to one monolithic relational DB to rule them all. What is the reality of the data? How does the application actually use this data? How big are the document objects being stored? Answer these questions and your schema will practically design itself.

这篇关于MongoDB-多对多关系?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！