我刚刚开始MongoDB（晚会，我知道......）
在考虑文档设计时，我仍然试图让10多年的关系DBing失去理智。
假设我有很多用户使用了很多应用。任何用户都可以使用多个应用，任何数量的用户都可以使用任何应用。
在登录程序中，我想访问用户使用的所有应用程序。在另一个程序中，我想获得特定应用程序的所有用户。
我应该有重复的数据吗？也许在App文档中有一组用户和用户文档中的一系列应用程序？这有意义吗？这是文档DB中的传统方法吗？
答案 0 :(得分：2)
好问题！
你有很多场景。 在Mongo中，您可以通过多种方式解决此问题： 使用SQL中的查找表或具有数组。 您应该考虑的是索引，与SQL中的索引相同，但这次您有更多选项。 由于它有很多种情况，我可能会使用查找表。 这是获取用户的应用和应用的用户的最有效方式。 数组不适合动态值，特别是如果您需要两个数组字段（app / user），而app.users数组字段将经常更改。 缺点是你可以“加入”并且必须从两个表中“选择”数据并自己“加入”，但这不应该是一个问题，特别是因为你总是可以缓存结果（应用程序中的本地缓存） ）如果要为用户字段添加索引，Mongo将以超快的速度返回结果
{
_id: "<appID>_<userID>" ,
user: "<userID>"
}
默认情况下_id索引。应该为“user”字段创建另一个索引，然后Mongo将btree加载到内存中，你们都很好。
答案 1 :(得分：1)
根据您的情况，您不需要重复数据。由于它是多对多的关系，并且数据会不断变化，因此您需要使用文档引用而不是文档嵌入。
所以你将有两个系列：
应用集合：
{
_id : appId,
app_name : "appname",
// other property of app
users : [userid1, userid2]
}
用户集合：
{
_id : userId,
// other details of user
apps: [appid1, appid2, ..]
}
正如您所提到的，您需要在app collection＆amp ;;用户集合中的应用程序数组。
当您在客户端中获取数据时，首先在用户登录时，您将从用户文档中获取应用程序ID数组。
然后，再次使用应用ID，您需要在应用集合中查询应用详情。
当我们使用参考时，这次往返肯定会在那里。但是你可以通过缓存细节来提高性能。通过适当的索引。
这在mongodb中是常规的，用于多对多的关系