MongoDB 文档设计的评论（及其回复评论）

Question

我有一个如下所示的模型：

class Comment {
    public string ID { get; set; }
    public string ArticleType { get; set; }
    public string ArticleID { get; set; }
    public string Body { get; set; }

    public DateTime DateCreated { get; set; }

    public string UserID { get; set; } 
}

我正在创建一个应用程序来存储有关应用程序中其他内容的评论 例如，如果评论是关于产品的，则 ArticleType 可以是“产品”，ArticleID 可以是产品 id...

我将使用 mongodb 来存储此数据，

我希望能够回复评论，并分层存储响应 我应该在评论文档中存储一个列表吗？

我阅读了 Rob Ashton 撰写的这篇文章这对于博客文章及其评论之类的内容是有意义的......

但是，在我的模型中，“回复评论”直接指父评论。

评论回复甚至还可以有回复，使它们变得x层深......？ 这是否超出了MapReduce类型查询的范围？

编辑：

“文章”可能是不好的术语 - ArticleType 和 ArticleId 只是将评论与特定“事物”联系起来的一种方式 - 例如，如果我们评论这个问题，articleType 可能是 stackOverflowQuestion id 为 5144273

如果我们对 eBay 拍卖进行评论，我们可以将articleType 设置为 ebay，articleId 设置为 1234902493984（商品编号）

希望这更有意义...

Answer 1

我看到三种可能的解决方案（这只是我的意见）：

1.

public class Comment 
{
  ...
  public List<Comment> ChildComments {get;set;}
}

优点：您可以轻松加载、显示分层数据。你不知道家长的评论和评论。
缺点：您无法使用某个 ID 查询和更新评论。

2.

public class Comment 
{
  ...
  public string ParentCommentId {get;set;}
}

优点：您可以根据需要查询/更新。
缺点：当您需要加载层次结构时，会对 mongo 发出大量请求。

3.我最喜欢的一个;) :

 public class Comment 
 {
   ...
   public string ParentCommentId {get;set;}
 }

 public class Article
 {
   ...
   public List<Comment> Comments {get;set;}
 }

优点：您可以根据需要查询/更新。您可以在一个请求中加载包含所有评论的文章。无需存储重复的 ArticleType 和 ArticleId
缺点：需要加载文章并在内存中构建层次结构。

希望这可以帮助您做出选择..

Answer 2

评论回复甚至可以有回复，使它们深x级......？

因此，如果您想对此进行建模，最简单的方法是为每个评论提供一个 Comments 属性列表。这为您提供了适合数据的自然层次结构。

这会超出mapreduce类型查询的范围吗？

不。Map 函数只是一个 JavaScript 方法。它可以调用其他方法，它可以递归地遍历一棵树。

您的模型：

关于您提出的模型，让我担心的一件事是您有 ID、ArticleID 和 ArticleType？您到底打算如何访问该对象？您计划建立什么类型的索引？

评论信息是否会在文章范围之外被访问？
您要加载带有“文章”的评论吗？
仅在文章本身内部存储 List 是否有意义？

您可以通过多种方式对此数据进行建模。所以这实际上取决于你想得到什么。您无法针对每个可能的查询进行优化。如果您可以告诉我们您想要快速执行哪些查询和用例，那么就可以更轻松地提供有关数据建模的建议。