"Rebuttals" and "Comments" - Two DB-Tables or One?

Question

I'm working on a project for a friend and I've come across a difficult decision. The project consists of essays, each of which can be challenged, and also commented on. The thing is this, only one person is able to challenge the essay, and then everybody else is locked out and can only comment.

The rebuttals can only be two responses deep, 2,000 words for the first and 500 words for the second. At that point, no more rebuttals - the rest of the discussion takes place in the comments (fixed length of n chars, unlike rebuttals) if the viewers feel the topic wasn't exhausted.

So I initially decided that rebuttals and comments were structurally the same thing, and I would merely add a boolean field within my comments table to indicate if the comment is_rebuttal. But I'm feeling a bit unsure about that direction.

What would the collective-you suggest? Each essay can have a discussion between two people only, and both only get to speak 2 times. Very similar to comments, but separate.

Answer 1

Well, hard to say without knowing more about the system. But I'd say, from what you write, yes, rebuttals & comments are similar and should be put into a single table.

My motto always is: When in doubt, use the simplest method. Which here is clearly a single table.

If later it turns out that separate tables are more useful, you can always refactor.

Answer 2

If comments and rebuttals have different maximum lengths, and different restrictions on how many you can have per essay, they sound like very different things to me. Your schema will be clearer if you create two tables for entities with different limitations, and establish different column and referential constraints.

Answer 3

So I'd probably have a table for 'conversations', with fields for the essay poster's userID, the single responder (initially NULL) and probably a title or abstract. Another table would contain 'essays' with fields for the essay or rebutter's userID, the conversationID, the body of the post, and a post count to put them in order. Finally, I'd have a 'comments' table with comment posters userIDs, essayID's to link them to essay posts, commentID's to put them in thread mode (if that's apropriate) and of course the comment body.