Question

Choice 1:
comments {commentid,replyto,comment}
//replyto will be null on many posts

Choice 2:
comments {commentid,comment}
replies {replyid, replyto, reply}

It looks like a matter of choice rather than linear benefit analysis at the moment.

Answer 1

In fact this is not ‘only’ matter of choice, but aware decision. Relational databases are not good at solving problems of hierarchical nature. There were tons of discussions, articles, and even books about that, so lets narrow the problem to your case.

The second choice would work fine ONLY if you were to allow replies to comments, and not to replies itself, thus this would be a tree with maximum 2 levels. That might be ok, but if you were to do that better solution would be to place everything with COMMENTS table, and add two columns: THREAD_ID (all the comments with the same THREAD_ID would belong to same thread), SEQ_NUM (or simply DATE would tell us which comment was first). Similar way of organising comments is implemented here on SO.

The first choice is quite simple and generic – but implements recurention with all its cons. Lets stop a bit and think… note that we are actually NOT building a tree, but a ‘forest’. We will have many commen threads and every single thread will be a separate tree – relatively small amount of data to organise. In that case I would add a THREAD_ID column to COMMENTS table and use only that table (it would be also good to set an composite index on COMMENTS table containing THREAD_ID and COMMENTID columns – in exactly that order).

So upon above I would choose “choice 1”.

Next decision should be about where to do the processing and comment tree construction? I would just get all the comments from the table an organise them on a controller (MVC) side, i.e. JAVA or C++. Traversing the list of comments and building the tree in Main Memory (using objects and pointers or hash tables) would be an easy thing. It is a good option also because small amount of nodes (comments and replies within one thread).