为不同供应商存储客户评论的正确关系数据库设计是什么？答案

【问题标题】：What is a correct relational database design for storing client reviews for different vedors?为不同供应商存储客户评论的正确关系数据库设计是什么？
【发布时间】：2021-09-15 19:06:59
【问题描述】：

我正在做一个数据库设计，我有一个包含供应商的表格，每个供应商都可以让人们审查它们。

这是我的表格（出于这个问题的目的，我保持简单）：

vendor_table

vendor_id | vendor_name | vendor_location | vendor_email       | vendor_phone
1         | User One    | LocationOne     | emailOne@test.com  | 000000001
2         | User Two    | LocationTwo     | emailTwo@test.com  | 000000002

reviews_table

review_id | customer_name | rating | review_text | vendor_id
1         | Customer One  | 5      | mediumtext  | 2
2         | Customer Two  | 2      | mediumtext  | 1
3         | Customer 3    | 5      | mediumtext  | 2
4         | Customer 4    | 5      | mediumtext  | 2

我的问题是：这有意义吗？使用review_id 和vendor_id 作为外键创建一个名为vendor_reviews 的链接表会更好吗？如果是这样，为什么它会比现在的设计更好？

【问题讨论】：

标签： mysql database database-design relational-database

【解决方案1】：

是的，构建一个桥接表来表示 n 对 m 关系是有意义的，这样审阅者就可以对每次销售的同一供应商进行审阅。但您需要稍微调整一下表格结构。

审查表

review_id | customer_id | rating | review_text | vendor_id

还有一个客户表

customer_id | customer_name .....

另一方面，如果您有 no 客户表，则不能有 n:m 关系。

而是保留您的设计，因为它只是供应商和审查之间的一对一关系

【讨论】：

我很难理解 n-m 关系。在我的情况下，审阅者将类似于博客上的公共评论部分。因此，任何人都可以提交评论。我在想的是每个评论者（因为他们实际上没有帐户）只会发布评论并将 vendor_id 放在同一行中。但我似乎无法弄清楚桥表 vendor_reviews 的意义（尽管我知道一个供应商可以有多个评论）。你有什么想法？
如果你有 no customer 表，你不能在 review 和 vendor 之间建立 n:m 关系，因为你在 review 和 vendor 之间是 1:1 的
这很有意义。谢谢！

【解决方案2】：

不是 1:1 - 每个“1”供应商都有“许多”评论。所以它是 2 个像 @nTuply 一样的表。

如果您不识别“客户”，则无需为他们提供表格。也就是说，任何人都可以写评论、起名字等。这使得它不是很多：很多。

如果是 1:1，你也可以合并表格。

1:many（或 many:1）——注意“many”（reviews.vendor_id）中的每一行到“1”（表vendors）的链接。您在vendors 中的vendor_id 上有一个索引——即PRIMARY KEY。如果要列出供应商的所有评论，则需要在 reviews 中添加 INDEX。 FOREIGN KEY 是可选的。

1:1 将共享一个主键。

Many:many 需要一个通常不超过两列的额外表——链接到这两个表的 id。两个FOREIGN KEYs 是可选的。更多关于 many:many -- http://mysql.rjweb.org/doc.php/index_cookbook_mysql#many_to_many_mapping_table

【讨论】：