views:

80

answers:

4

I have a table of users and a table of questions. The questions table will have records that represent "Questions", "Answers" and "Comments" to questions or answers. I'd like to create a dashboard for each user in which its possible to see activities related to questions and answers. For example if user A creates a question and user B responds with an answer and user C responds with a comment to user B's answer, then users A and B are able to see all of that activities in their dashboards.

This works similar to the way that Facebook home page works where if I put up a video I can see people's comments on my video.

Can anyone suggest a simple way to model this in a database?

+2  A: 

I believe Facebook et. al. handle this by having a separate database of generic "update" records, which have a short description of the action taken. Whenever someone performs an action on the site that should show up in the Wall, a record is inserted in the update database as well.

ceejayoz
I have tried something very similar to your suggestion in which I have a table of updates. Each row is associated with a user (the person whose action resulted in creation of a record in update table) and the description of the action. This works well when I want to find actions taken by people I follow because I can query by their IDs. But I can't find a clean way to also retrieve associated actions that may have been taken by users I don't follow. I'm trying to keep this as simple as possible to avoid having to join with other tables or perform multiple queries. Any thoughts will help :)
Am
A: 

Ok here is what you can try.. you can't mess up questions, answers and their comments in the same table.. One question can have many answers and different answers can have different comments. Keeping all of them in same table will be quite messy and not recommended (against the rules of RDBMS). Make three separate tables one for Questions, one for Answers and one for Comments. Define relations between them based on the primary and foreign keys.. So at any point time in question table you have all the questions asked by all the users. The Answer table will have all the answers posted corresponding to that particular question and the comment table will have the comments to the corresponding answer. Maintaining proper supporting columns in all tables you can easily manage what you want. At any point of time you can see all the answers related to a particular question by joining Question and Answer table, also you can view all the comments made on a particular answer by joining Answer and Comment table..

Hope this gives you an IDEA..

Gourav C
I know of textbook schema design techniques however performance have been a serious consideration. With my current system i can list a question along with it's answers and comments using a single join-less query. IMO your suggestion is nice from the traditional schema design perspective but in real life situations sometimes optimizations like the one I described pay a great dividends.
Am
true, but managing in a single table will work perfect with test data.. but what when the frequency of data is quite hign... so that all depends on your analysis of data frequency..
Gourav C
A: 

If you are going to use one table, you might want to try something like this.

TABLE{ ID, ParentID, UserID, Type, Text, PostDtm }

This gives you a basic tree structure in one table.

The trade off is that you may have more complex queries and there may be more of them needed to achieve what you want.

make sure you have indexes on the id columns at minimum.

I still am unsure about how much performance you need. A site like facebook has to consider much more than table level optimizations. For most sites a textbook relational model can be queried more efficiently than this model. What are your performance targets?

Jim
Well, to beat Facebook's traffic you must be really big and better. I'm not talking about that kind of traffic but I'm thinking the traffic for above average site. "For most sites a textbook relational model can be queried more efficiently than this model." I'm not sure how you assumed that and I could be wrong but I have a strong feeling that joins operations are heavier to perform than a basic query on one table. Either way I've tested this model and seems to work just fine in the past.
Am
A: 

enter code here@Am, my assumption is to bite the bullet and if using MySQL then use relationships or move to a different type of database if you want to totally get away from tables with relationships. You desire a "clean" implementation of atypical of the RDB model. For RDB, I suggest you use four tables: users, user_map, questions, responses. Responses are categorical (e.g. to a Question or Answer) so track which type it is where the only foreign keys in any table are question.id and user.id.

Users: id, name
User_map (can be used with Questions and/or Responses to join the data): u_id, q_id
Questions: id, text_value
Responses: id, q_id, text_value, category

Have you truly determined that relationships are something you need to optimize out or are just over analyzing it? If you need to get away from a relationship based database then I would suggest looking into technologies that are built for it.

Jamie Altizer
There is no advantage in creating extra tables when all questions, answers and comments are the same thing at their very basic. I see a lot of answers here telling me I have to break up my table. My question really has nothing to do with having one table vs three. What everyone here is suggesting except for @ceejayoz, is 101 DB design and even if I break up my current design and do things as you are suggesting my original question won't be answered! I too know what pretty design looks like but I really like to learn an optimized way of doing feed walls.
Am