我很好奇如何构建一个具有多对多关系、可能有数万条记录的 MongoDB。
假设您有一个餐厅数据库，可以跟踪大量餐厅以及所有入住过这些餐厅的人。因此，用户可能想要查找一个人并查看他们已签到的所有餐厅，而且还想查找一家餐厅并查看所有已签到的人。
如何以一种有意义且易于搜索和更新的方式构建它？
您给出的示例与大多数现实世界中的多对多关系示例一样，实际上是一个示例几对几关系。您可能有许多餐厅和许多食客，但与整个集合相比，任何给定的餐厅只为一小部分食客提供服务，并且大多数单独的食客只会访问一小部分餐厅。这听起来像是一个稀疏链接的网络，其中链接密度比明显低于 1。
为了测量网络的链接密度（边缘密度），我们计算
现有链接 m 与可能链接总数的比率。
对于 N 个节点的网络，网络链路密度为 D = m /
0.5*N*(N-1) 全连接网络的（最大）链路密度 D 为 1。 -网络科学 http://www.network-science.org/highly-connected-society-dense-social-complex-networks.html
但是，您问的是多对多，那么我们以神经网络为例怎么样？神经网络通常形成密集网络，因此代表真正的多对多网络。在这种情况下，答案很简单——不要使用 mongoDB。使用根据您的具体要求量身定制的自定义结构和序列化策略。毕竟，真正的多对多关系几乎总是异常值，因此需要进行特定的处理。
话虽如此，建模更常见几对几mongoDB 中的关系可以在不牺牲丰富文档结构的情况下实现，而如何实现这一点取决于您的访问模式。
因此，对于餐厅/食客网络示例，如果您通常要查询餐厅的食客信息，那么您将创建每个餐厅保存的diner_ids 数组。另一种方式意味着每个用餐者持有一系列的restaurant_ids。两者都是为了双向查询能力。
必须小心，因为 mongoDB 中没有foreign_key 约束，因此维护数据的引用完整性是您的责任。
如果性能对您来说最重要，那么您可能希望将数据嵌入到每个文档中，而不是使用 id 引用它。这是读取性能更高的选项（写入性能不那么高），因为所有数据都可以一次从磁盘中取出。这意味着您在更新数据值时需要做更多工作以确保数据的完整性，但这通常并不像乍看起来那么可怕。食客真正改名的频率有多少？根据文档大小，您可能不一定要嵌入完整文档，数据子集加上指向完整记录的 id 通常就可以解决问题。
简而言之，mongoDB 模式设计应该由应用程序需求驱动。不同的应用程序有不同的模式，而不是用一个单一的关系数据库来统治它们。数据的真实情况如何？应用程序实际上如何使用这些数据？存储的文档对象有多大？回答这些问题，您的模式实际上就会自行设计。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
