在一张表中对数据进行建模与使用两张表相比的优点

Question

假设您正在使用 MySQL 对问答数据库进行建模，我知道有两种方法可以实现模型架构：

1. 使用“typeId”为问题和答案创建一个表
2. 创建两个单独的表；一个用于提问，一个用于回答

任何人都可以详细说明这两种方法的优点和缺点，以及为什么您会使用一种方法而不是另一种方法？

我自己的观察：

1. 方法 2 更加规范化
2. 方法 2 需要两个用于 Q 和 A 的“评论”表，或者一个具有复合 PK 的表； （Q 和 A 可能具有相同的 ID）
3. 方法 1 可能因自连接等而变得非常复杂

Answer 1

设计的具体内容实际上取决于您的要求、您想要实现的目标以及您的数据库有多大。

单表方法：
如果您只为每个问题提供/允许一个答案（常见问题解答），您可能可以使用单个表，此时您只有 id,question,answer 字段，而问题没有添加到数据库直到给出答案，或者在答案可用时更新行。

2表方法：
一旦每个问题可能有多个答案/评论。我可以选择一个与 @Spredzy 稍有不同的模型，因为为了简单起见，我只包含“电子邮件”之类的所有内容：message_id、in_reply_to、timestamp、text。这种简单性不允许您标记特定的内容（答案 VS 评论，除非只有一个答案并且 in_reply_to 答案变成像 SO 那样的评论）。问题是带有 in_reply_to IS NULL 的问题。

3/更多表方法：
如果您确实希望通过在主表上设置 FIXED-ROW 长度来提高性能，并且不需要显示问题和答案的摘录，而只想知道数字。您可以将文本、任何附件等分开。或者只是因为您想避免自连接，如 @orangepips 所建议的：“最后，自连接很糟糕，并且是一种降低性能的绝佳方法。” ）并为所有内容都有一个单独的表。

Answer 2

将其建模为两个表。问题可以有多个答案。为问题和答案创建单独的评论表；我认为最有可能的用例不会看到注释数据混合在单个 DML 语句中。

如果您表示对象模型的继承，则由类型列区分的单个表可能有意义，但这里的情况并非如此。此外，对于任何查看该模式的人来说，该表的意图都是混乱的，因为他们需要知道该类型的枚举可能性；我认为可能是一个查找表，但对于两种可能性 - 没有更多 - 似乎是一种浪费。

最后，自连接很糟糕，并提供了一种扼杀性能的极好方法。

Answer 3

我会创建 2 个表：

一个代表问题、答案和评论。如果您仔细观察，它们具有相同的核心数据：user_id、文本、日期，加上 type_id 字段以及您可能需要的所有其他字段。

另一个表将是一个非常简单的表：类型

type_id   type_desc
xxx-x-xx  question
xxx-x-xx  answer
xxx-x-xx  comment

通过这样做，您的模型将具有高度可扩展性，速度更快，并且不会重复数据（规范化）。

最后，从技术上讲，要获得所有问题或一个问题的所有答案，这只是一个简单的连接。

希望它能有所帮助，

Answer 4

每种数据类型一张表。如果问题和答案相同（就像 OOP 中的对象一样），一张表就足够了。如果没有，就不会。

具有复合 PK 的单个评论表是正确的，因为评论仍然属于一种类型的对象：评论。他们可以引用 Q 和 A 的事实并不影响这一点。