我有一个集合用户，即姓名、密码、电子邮件等。
我还有一个集合组，每个组都有它的成员 - 用户数组。
我应该如何设计我的数据库？我清楚地看到了两种方法：
方式 1（类似 MySQL）：每个用户都有一个 _id，所以我只是将其放入 members 数组中，就这样。
方式2：复制整个用户文档并添加一些字段。
在 MongoDB 网站上，他们说重复数据无需担心存储价格低。他们还说我们应该避免在读取数据时使用 JOIN。
【问题讨论】：
标签： mongodb database-design database
重复数据无需担心
这在更新时需要担心。假设您在每个文档中都有嵌套和重复的用户详细信息。当用户更改姓名时会发生什么？您必须在每个文档中更新该用户的每个实例。
注意区分数据和实体。用户是一个实体，请在复制实体之前仔细考虑，因为以后修复它可能会很辛苦。
就个人而言，除非您发现自己处于性能太慢而无法实时加入的情况，否则我会拆分它们。然后，也只有这样，才考虑合并。
【讨论】：
实际上，这个问题的答案取决于您正在设计什么样的屏幕以及您要进行什么样的查询来获取数据。让我们来看看每个选项的优缺点，这将帮助您权衡每个选项。
方式 1 :- 将 user_ids 数组放入组集合中
优点
1) 如果您有一个屏幕显示特定组的组详细信息以及属于该组的所有成员 (users_ids) 的列表，那么一个查询可以获取此屏幕所需的所有详细信息，而且速度也会更快。
缺点
1) 如果在组详细信息屏幕中，您必须显示用户详细信息以及组详细信息，那么由于 mongodb 不提供任何连接，您将在单独的查询中获取用户详细信息，并将在客户端上同时加入边。这可能会影响性能。
2) 如果您有一个显示用户详细信息和他/她所属的所有组的屏幕，那么您将在组集合的用户数组中搜索 user_id。如果您预计组中的成员数量非常多（数百万），那么在数组中搜索可能会导致巨大的性能影响。
方式 2 :- 在组集合内复制用户文档
重复数据在 Mongodb 中不是问题，但你应该有一个很好的理由。当关系是 1:few 而不是 1:many 时，拇指规则应该是重复数据。
优点
1) 这种方法将使您免于在客户端加入组和用户集合，因为一个查询可以获取组及其用户的所有详细信息。
缺点
1) 假设您有一百万个组，而 user_id_1 属于 100,000 个组，那么每当您对 user_id_1 进行更新时，您就必须更新 100,000 个文档。这可能再次导致巨大的性能影响。
2) 另外，如果有大量用户订阅 1 个组，则该组的文档大小会不断增加。在 Mongodb The maximum BSON document size is 16 megabytes 中，这意味着您不能拥有大于 16MB 的文档，因此您不能无限地将用户添加到组中。这会限制您的功能。
方式 3：- 在用户集合中嵌入组详细信息
优点
1) 一个查询可以获取用户详细信息以及该用户所属所有组的所有详细信息。
2) 如果您希望一个组中的用户很少，那么用户文档中的组数组将很少。这不会超过 16MB 的限制。
缺点
1) 如果您期望用户可以订阅很多组（数百万），那么用户文档可能会超过 16MB 的限制。
2) 此外，如果您在组详细信息中的更新非常频繁，那么您将不得不在许多用户文档中更新相同的内容。
您还可以通过以下链接获取有关数据模型设计的更多详细信息：- https://docs.mongodb.org/manual/core/data-model-design/
【讨论】：
这取决于您将如何在应用程序中使用数据。
如果您有 2 个以上的组，并且您必须在所有组中搜索用户，则将用户文档嵌入组中（方式 2）不是一个好主意。所以在这种情况下我建议使用方式1。
如果你只有2个组或者用户组在你的应用程序查询之前就知道了，那么使用方式2。
我想分离数据是要走的路，因为直接更新、获取和删除用户数据会更好。
【讨论】：