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?
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.