我正在尝试使用 MongoDB、C# 和NoRM来处理一些示例项目，但在这一点上，我很难将我的头脑围绕在数据模型上。用RDBMS的相关数据是没有问题的。然而，在 MongoDB 中，我很难决定如何处理它们。
让我们以 StackOverflow 为例……我完全理解问题页面上的大部分数据都应该包含在一个文档中。标题、问题文本、修订、评论……都在一个文档对象中。
我开始变得模糊的地方是用户数据的问题，如用户名、头像、声誉（变化尤其频繁）......每次用户发生变化时，您是否会非规范化和更新数千条文档记录，或者您是否以某种方式链接数据在一起？
在不导致每次页面加载时发生大量查询的情况下，完成用户关系的最有效方法是什么？我注意到了DbReference<T>NoRM 中的类型，但还没有找到使用它的好方法。如果我有可以为空的可选关系怎么办？
感谢您的洞察力！
我发现的平衡是使用 SQL 作为规范化数据库和 Mongo 作为非规范化副本。我使用 ESB 使它们保持同步。我使用了一个概念，我称之为“准备好的文档”和“存储的文档”。存储的文档是只保存在 mongo 中的数据。对于非关系数据很有用。准备好的文档包含可以使用规范化数据库中的数据重建的数据。它们在某种程度上充当活缓存 - 如果数据不同步，它们可以从头开始重建（在复杂的文档中，这是一个昂贵的过程，因为这些文档需要重建许多查询）。它们也可以一次更新一个字段。这就是服务总线的用武之地。
发挥每个数据库的优势。允许 SQL 成为确保数据完整性的写入数据库。让 Mongo 成为一个速度极快且可以包含子文档的只读数据库，这样您就需要更少的查询。
** 编辑 ** 我刚刚重新阅读了您的问题并意识到您的实际要求。我留下我原来的答案，以防万一它有帮助。
我处理您给出的 Stackoverflow 示例的方式是将用户 ID 存储在每个评论中。您将加载包含所有评论的帖子。那是一个查询。
然后，您将遍历评论数据并提取需要加载的用户 ID 数组。然后将它们作为批处理查询加载（使用 Q.In() 查询运算符）。总共有两个查询。然后，您需要将数据合并为最终形式。您需要在何时这样做和何时使用类似 ESB 之类的工具来手动更新每个文档之间取得平衡。使用最适合数据结构的每个单独场景的方法。
尝试研究cqrs 和事件溯源架构。这将允许您按队列更新所有这些数据。
为什么要避免非规范化和更新“数千条文档记录”？Mongodb db 专为非规范化而设计。Stackoverlow 在后台处理数百万个不同的数据。有些数据可能会在短时间内过时，这没关系。
所以上面说的主要思想是你应该有非规范化的文档以便在 ui 上快速显示它们。
您不能以任何方式通过引用的文档进行查询，您需要非规范化。
我也建议看看cqrs架构。
我认为你需要取得平衡。
如果我是你，我只会在每篇文章中引用用户 ID 而不是他们的姓名/声誉。
不过，与 RDBMS 不同的是，您可以选择在文档中嵌入注释。