MongoDB document design for comments (and their reply comments)

I have a model that looks like:

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; } 
}

I am creating an app to store comments about other stuff in our application For example, if the comment was regarding a pro开发者_高级运维duct, the ArticleType could be “product” and the ArticleID would be the product id...

I am going to use mongodb to store this data

I want to be able to reply to a comment, and store the response hierarchically Should I store a List within the comment doc?

I read this article by Rob Ashton Which makes sense for things like a blog post, and it’s comments...

However, in my model, the “reply comments” refer directly to the parent comment.

Comment replies could also even have replies, making them x levels deep...? Would this be out of the scope of map reduce type query?

Edit:

"article" is probably bad terminology - ArticleType and ArticleId was just a way of tying a comment to a particular "thing" - for example, if we were commenting on this question, articleType could be stackOverflowQuestion and id would be 5144273

If we were commenting on an ebay auction, we could have articleType as ebay and articleId as 1234902493984 (item number)

Hopefully that makes more sense...

I see three posible solutions(it just my opinion):

1.

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

Pros: you can easy load, display hierarchical data. you don't know parent comment from comment.
Cons: you can't query and update comment with some id.

2.

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

Pros: You can query/update as you want.
Cons: Big amount of requests to mongo when you need load hierarchy.

3.My favorite one ;) :

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

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

Pros: You can query/update as you want. You can load article with all comments in one request. No need to store redurant ArticleType and ArticleId
Cons: Need to load article and build hierarchy in memory.

Hope this help you make choice..

Comment replies could also even have replies, making them x levels deep...?

So if you wanted to model this, the easy way to do this is to give each comment a list of Comments property. This gives you a natural hierarchical structure that fits the data.

Would this be out of the scope of map reduce type query?

No. A Map function is just a javascript method. It can call other methods, it can recursively walk a tree.

Your model:

One thing that worries me about your proposed model is that you have an ID and an ArticleID and an ArticleType? How exactly are you planning to access this object? What type of indexes were you planning?

Is the comment information going to be accessed outside the scope of the article? Are you going to load the comments with the "article"? Does it make sense to just store a List<Comments> inside of the article itself?

There are several ways you could model this data. So it's really going to depend on what you want to get out. You can't optimize for every possible query. If you can tell us which queries and use cases you want to make fast, then it's easier to provide advice on modeling the data.