MongoDB - 多对多关系？

Question

我很好奇如何构建一个拥有多对多关系的MongoDB，可能有数万条记录。

假设您有一个餐馆数据库，可以跟踪大量的餐馆和所有已经入住这些餐馆的人。 因此，用户可能想要查找一个人并查看他们检查过的所有餐馆，还可以查找餐馆并查看已登记的所有人。

如何以一种有意义且易于搜索和更新的方式构建它？

Answer 1

您提供的示例与大多数真实世界的多对多关系示例一样，实际上是少数关系的一个示例。 您可能有许多餐馆和许多用餐者，但与整套餐厅相比，任何一家餐厅只供应一小部分食客，大多数个人用餐者只会访问一小部分餐馆。 这听起来像一个稀疏链接的网络，其链路密度比明显低于1。

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

但是，您询问了多对多，那么我们如何以神经网络为例呢？ 神经网络通常形成密集网络，因此代表真正的多对多网络。 在这种情况下答案很简单 - 不要使用mongoDB。 使用根据您的特定要求定制的自定义结构和序列化策略。 毕竟，真正的多对多关系几乎总是异常，因此可以证明具体的治疗方法是正确的。

话虽如此，可以在不牺牲丰富的文档结构的情况下实现对mongoDB中更常见的少数关系的建模，以及如何实现这一点取决于您的访问模式。

因此，通过餐厅/餐馆网络示例，如果您通常要在其食客上查询餐馆，那么您将创建一个与每个餐厅一起保存的diner_ids数组。 另一种方式意味着每个用餐者都会举办一系列restaurant_ids。 两者都用于双向查询能力。

必须小心，因为mongoDB中没有foreign_key约束，因此维护数据的引用完整性是您的责任。

如果性能对您来说最重要，那么您可能希望将数据嵌入到每个文档中，而不是使用id引用它。 这是用于读取的更高性能选项（不是用于写入），因为所有数据都可以在一次命中中从磁盘中拉出。 这意味着在更新数据值时需要做更多工作以确保数据的完整性，但通常这并不像它最初看起来那么可怕。 用餐者经常改变名字的频率是多少？ 根据文档大小的不同，您可能不一定要嵌入完整的文档，数据的子集加上指向完整记录的id通常会起作用。

简而言之，mongoDB架构设计应该由应用程序要求驱动。 不同应用程序的不同模式，而不是一个单片关系数据库来统治它们。 数据的实际情况是什么？ 应用程序如何实际使用此数据？ 文件对象的存储量有多大？ 回答这些问题，您的架构将实际设计自己。

Answer 2

我会创建一个checkins或visits集合。 当用户访问该餐馆时，创建一个引用用户和餐馆的新文档。 这是相当干净和直接的