2

我有一个看起来像的模型：

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级......？这会超出 map reduce 类型查询的范围吗？

编辑：

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

如果我们对 ebay 拍卖发表评论，我们可以将 articleType 设为 ebay，将 articleId 设为 1234902493984（项目编号）

希望这更有意义......

4

2 回答 2

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
缺点：需要加载文章并在内存中构建层次结构。

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

于 2011-02-28T17:21:20.187 回答
1

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

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

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

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

您的型号：

关于您提出的模型让我担心的一件事是您有一个 ID、一个 ArticleID 和一个 ArticleType？您打算如何访问该对象？您计划使用哪种类型的索引？

评论信息是否会在文章范围之外被访问？你打算用“文章”加载评论吗？List<Comments>只存储文章本身的内部是否有意义？

有几种方法可以对这些数据进行建模。所以这真的取决于你想得到什么。您无法针对每个可能的查询进行优化。如果您可以告诉我们您希望快速完成哪些查询和用例，那么就更容易提供有关数据建模的建议。

于 2011-02-28T19:46:55.053 回答