关联表的优缺点是什么？

Question

在RDBMS中，我相信有几种方法可以设计表之间的关系。因此，我想问一下创建关系与关联表和没有关联表之间的专业和缺点是什么？ STRONG>。是否有正式的解决方案来决定两者？

使用通用表格，下面我演示了我的意思：

示例＃1（没有关联表）

用户

+----+-----------------------------+---------+
| id |            text             | user_id |
+----+-----------------------------+---------+
|  1 | Lorem ipsum dolor sit amet. |       1 |
|  2 | Praesent ultricies libero.  |       2 |
|  3 | Donec eget blandit nunc.    |       3 |
+----+-----------------------------+---------+

评论

comments

注意：对评论作者的引用存储在+----+-------+ | id | name | +----+-------+ | 1 | John | | 2 | James | | 3 | Jacob | +----+-------+ 。

中

示例＃2（使用关联表）

用户

+----+-----------------------------+  
| id |                        text |  
+----+-----------------------------+  
| 1  | Lorem ipsum dolor sit amet. |  
| 2  |  Praesent ultricies libero. |  
| 3  |    Donec eget blandit nunc. |  
+----+-----------------------------+  

评论

+----+--------------+-----------+
| id | comment_id   | user_id   |
+----+--------------+-----------+
| 1  | 1            |        1  |
| 2  | 2            |        2  |
| 3  | 3            |        3  |  
+----+--------------+-----------+

comment_user

comment_user

注意：对评论作者的引用存储在{{1}}。

中

Answer 1

您正在使用术语＆＃34;数据透视表＆＃34;不正确。中间表有各种术语;常用名称包括联结表和关联表。优点和缺点也很奇怪 - 您正在邀请意见，这在Stack Overflow上是明确禁止的。但是，你的问题是相当误导的。因此，值得回答。

你的两个选择做不同的事情。第一个实现1：n关系。给定用户可以有很多评论。但评论只能属于单个用户。

第二个实现m：n关系。给定用户可以有很多评论。给定的评论也可以有很多用户。

显然，1：n关系可以作为m：n关系的特例来实现。然而，这是过度和低效的。

用户和评论之间的关系通常为1：n，因此第一个结构似乎更自然。

Answer 2

没有正式的，没有。

优点：

• 关联表可以处理一对一，一对多和多对多关系，具体取决于您定义的键。
• 您可以在没有用户的情况下拥有评论（不使用NULL）。
• 可以将关联表添加到现有数据库，而无需修改现有表。

缺点：

• 额外的表格稍微混乱了你的架构。
• 查询时的额外连接有点复杂，可能会影响性能。
• 确保每个评论都有一个用户（如果这是一个要求）更复杂。

另外，comment_user表中的id列似乎毫无意义。