Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I have a scenario similar to as depicted below,

public class Post {
    private int id;
    private int postType;
    private int score;
    private User originalPoster;
    private String title;
    private String body;
    private String tags;

}

public class Comment {
    private int id;
    private int postId;
    private String text;
    private int score;
    private User userId;
}

public class User {
    int id;
    String displayName;
    int score;
}

How do I model my MongoDb document/domain object?

My initial options are,

1) Have a separate Post and Comment collections and handle updates/retrievals hide behind my Rest Resource with possible duplicate of Comment in both Post and Comment.

2) Have a single Document Post and include everything in it and have only one Rest Resource? This will limit my url templates or need for complex data retrievals at MongoDB end.

Whether I should go with 1) or 2) or there is other approach where I can have flexibility of urltemplates and minimize the NoSQL interactions?

share|improve this question
    
Why would you have duplications of the comment in the Post and Comment resources? Maybe just have a link in the Comment collection that points to the parent? I'm actually dealing with the same issue. How to organize REST resources to take advantage of Mongo's strong points. Which approach did you end up going with? –  Leonidas Mar 22 '13 at 16:16

1 Answer 1

I'll preface this with a disclaimer -- I have zero seat time in MongoDb. I do have a fair amount of seat time in some other document databases and I think these problems are similar. But there could be some mongo specific stuff I might miss here -- I have no idea what url templates are or how one would use them.

With document databases, in general the best approach would be to think about your transaction boundaries here -- that should be how one defines what is in a given document. For example, are you always dealing with posts and comments or sometimes just posts? Do you have angles where you need to deal with comments on an individual level?

Another issue is practical concerns -- like the case where you have a hot post with 15,000 comments. Even at 1kb / comment you are looking at some pretty nasty load times if you just want to show that post.

Anyhow, I would probably make everything a post and add a field for "parentPostId" or something like that. Then I would model the PostsWithComments as an index rather than a concrete document which should give you the best of both worlds -- easy to get full post data while keeping writes and other maintenance sane. Indexes are your best friend here.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.