我有一个模型看起来像:
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存储这些数据。
我希望能够回复评论,并按层次存储响应,是否应该在注释文档中存储列表?
我阅读这篇文章的文章,罗布阿什顿,这是有意义的事情,如博客,它的评论.
但是,在我的模型中,“回复注释”直接引用父注释。
评论回复甚至也可能有回复,使它们具有x级深度.?这是否超出了映射缩减类型查询的范围?
编辑:
“ArticleType”可能是不好的术语-- articleType和ArticleId只是将评论与特定的“事物”联系起来的一种方式--例如,如果我们对这个问题进行评论,articleType可能是stackOverflowQuestion,id是5144273。
如果我们是在ebay拍卖会上发表评论,我们可以让articleType作为ebay,articleId作为1234902493984 (商品编号)。
希望这更有意义..。
发布于 2011-02-28 17:21:20
我看到了三个可行的解决方案(这只是我的意见):
1.
public class Comment
{
...
public List<Comment> ChildComments {get;set;}
}
Pros:您可以轻松加载,显示分层数据。从评论中你不知道父母的评论。
Cons:,您不能使用某些id查询和更新评论。
2.
public class Comment
{
...
public string ParentCommentId {get;set;}
}
Pros:您可以随意查询/更新。
Cons:当您需要加载层次结构时,向mongo请求的数量很大。
3.我最喜欢的一个;):
public class Comment
{
...
public string ParentCommentId {get;set;}
}
public class Article
{
...
public List<Comment> Comments {get;set;}
}
Pros:您可以随意查询/更新。您可以在一个请求中加载带有所有注释的文章。不需要存储红色的ArticleType和ArticleId
Cons:需要加载文章并在内存中构建层次结构。
希望这能帮你做出选择。
发布于 2011-02-28 19:46:55
评论回复甚至也可能有回复,使它们具有x级深度.?
因此,如果您想要对此进行建模,那么最简单的方法就是为每个注释提供一个注释属性列表。这为您提供了一种适合数据的自然层次结构。
这是否超出了映射缩减类型查询的范围?
不是的。Map函数只是一个javascript方法。它可以调用其他方法,也可以递归地遍历一棵树。
您的模型:
我对您提议的模型感到担忧的一点是,您有一个ID、一个ArticleID和一个ArticleType?您究竟打算如何访问这个对象?你在计划什么类型的索引?
评论信息是否将被访问到文章的范围之外?你要用“文章”来载入评论吗?只在文章本身中存储一个List<Comments>
是否有意义?
有几种方法可以对这些数据进行建模。所以这将取决于你想要得到什么。您不能为每个可能的查询进行优化。如果您可以告诉我们您希望快速生成哪些查询和用例,那么提供有关数据建模的建议就更容易了。
https://stackoverflow.com/questions/5144273
复制相似问题