Help Needed with nested Comment Schema
Hey frens. I'm building a stack overflow clone for poultry farmers.
For a commenting system, how should I go about modeling comments, and their replies?
I watched a great tutorial by MonsterLessons Academy. https://www.youtube.com/watch?v=sjAeLwuezxo
Oleksandr doesn't distinguish between comments and replies, but just adds a "parentId " field, which is null if it is just a regular comment.
But when I look at a particular reply from a facebook thread, they provide a reply_comment_id . Which makes me think they have a more intricate model. For additional context, facebook stops after replies-to-replies.
www.facebook.com/
groups/123456789/
posts/1234567890/
? comment_id=123412341234
& reply_comment_id=123456789012345
Should I ...
(A) treat all comments the same (whether they're nested or not) and simply add a field to distinguish it as a child ?
(B) Or should I add another table just for replies ?
I'm sure there's a trade-off for simplicity, scaling, performance etc. ?
For a commenting system, how should I go about modeling comments, and their replies?
I watched a great tutorial by MonsterLessons Academy. https://www.youtube.com/watch?v=sjAeLwuezxo
Oleksandr doesn't distinguish between comments and replies, but just adds a "parentId " field, which is null if it is just a regular comment.
But when I look at a particular reply from a facebook thread, they provide a reply_comment_id . Which makes me think they have a more intricate model. For additional context, facebook stops after replies-to-replies.
www.facebook.com/
groups/123456789/
posts/1234567890/
? comment_id=123412341234
& reply_comment_id=123456789012345
Should I ...
(A) treat all comments the same (whether they're nested or not) and simply add a field to distinguish it as a child ?
(B) Or should I add another table just for replies ?
I'm sure there's a trade-off for simplicity, scaling, performance etc. ?
