Assuming you were modeling a Q&A database using MySQL, I am aware of two ways to approach the model architecture:
- Create a single table for questions and answers with a “typeId”
- Create two separate tables; one for questions and one for answers
Can anyone elaborate on the advantages and disadvantages of both approaches, and why you would use one approach over the other?
My own observations:
- Approach 2 is more normalized
- Approach 2 requires two “comments” tables for Q’s and A’s or a single table with composite PKs; (Q’s & A’s may identical IDs)
- Approach 1 can become very complicated with self joins and so on
The specific of the design would really depend of your requirements and what you want to achieve and how huge your database would be.
1-table approach:
You may be able to use a single table in the case where you only provide/allow one answer per question (à la FAQ), where you would only have
id,question,answerfields and questions are not added to DB until answer is given, or update the row when answer is available.2-table approch:
As soon as there may be more than one answer/comment per question. I could choose a model a little bit different than @Spredzy’s as I would just include everything just like “emails”:
message_id, in_reply_to, timestamp, textfor simplicity. This simplicity will not allow you to tag specific (answers VS comments unless only one answer and in_reply_to answer becomes comments like on SO). Questions are those within_reply_to IS NULL.3/more-table approach:
If you really want performance by having FIXED-ROW length on the main table and don’t need to display excerpt of questions and answers, but only want to know numbers. You would separate the text, any attachments, etc. Or just because you would want to avoid self joins as suggested by @orangepips: “Finally, self joins suck and present an excellent way to kill performance.“) and have a separate tables for everything.