一对多关系的正确数据库模式答案

【问题标题】：The correct database schema for one-to-many relationship一对多关系的正确数据库模式
【发布时间】：2015-12-31 19:32:23
【问题描述】：

我正在建立一个关于汽车的爱好网站。如果用户点击汽车，我想显示所选汽车的类似汽车列表。

我有一个主表，用于存储有关每辆车的基本信息 CarDataMain，表中的两列是 CarID (Pk) 和 SimilarCarsID (Fk)。

我有另一个名为“SimilarCars”的表，它有三列； SimilarCarsID (Pk)、CarGroupID 和 CarID。

所以 SimilarCars 表中的 SimilarCarsID 列与 CarDataMain 表中的 SimilarCarsID 列有关系。

这是正确的方法，还是“最佳实践”？

每辆车只能属于一个 CarGroup (CarGroupID)。

另一种解决方案是创建第三个表，女巫持有 CarDataMain 和 SimilarCars-data 之间的关系，但由于存在一对多的关系，我想这是过度杀戮？但是，这样我可以在 CarDataMain 中为所有属于同一个 CarGroup 的汽车放置相同的外键值，女巫在某种程度上感觉很吸引人……

如果您理解我的意思，第三种解决方案是跳过 CarDataMain 中的 SimilarCarsID 列，并将 CarID 设置为 SimilarCars 表中的外键。但我想这种解决方案有一些缺点……

抱歉新手问题（如果这个问题之前已经提出过），但我想在开始之前把它弄好:)

路德

【问题讨论】：

【解决方案1】：

注意：重写

表格

GroupID 可能不是必需的。如果Name 是唯一的，则将其用作主键。

这是一个连接表。在这里，您可以将给定的汽车映射到许多组，并将给定的组映射到许多汽车。

我可能会误解，但似乎您想将汽车匹配为相似，没有特别的原因。如果你想按组匹配，那就是上面；如果你想要“这 2 辆车很相似，句号”，就可以了。这对各组并不相互排斥。

一个约束，因此 CarId 不能匹配 SimilarCarID -- 除非您确实希望汽车与其自身相似。但如果是这样，那么只需阅读汽车表即可。

【讨论】：

不赘述，让我们假设我所描述的就是我想要的（一个 SimilarCars 表）。（我已经写了详细的解释，但它包含的字符太多，对不起......）。
有关我为什么需要 SimilarCars 表的详细信息，请参阅我对 JBrooks 的回答。但是，您在上面写的关于“SimilarCar”的部分感觉很到位！考虑到我对 JBrooks 的回答，我想这就是要走的路吗？非常感谢你们。

【解决方案2】：

我认为你的概念需要先弄清楚。 “同类车”不是属于同一“组”的车吗？如果是这样，您只需要 1 个学期。由于“组”是保留字，因此最好使用其他词。

我会选择“类别”这个词。所以我的 Cars 表会有一个 CategoryId 列。想象一下前端有人要添加新车的页面，他们不会有一个下拉列表来选择类别吗？

所以我的模型是：

Cars
-Id (PK)
-Name
-CategoryId  (FK to Categories)
...

Categories
-Id (PK)
-Name

【讨论】：

感谢您的回答。我所做的和你上面的模型完全一样。 “问题”是同一类别的汽车仍然可能是非常不同的汽车。正在看保时捷卡宴的用户不太可能对现代圣达菲感兴趣，反之亦然。因此，当用户查看保时捷卡宴时，宝马 X5 和奥迪 Q7 等汽车将作为类似汽车显示在列表中。等等。因此我的 SimilarCars 表。 :)
这是怎么回事？您声明一辆车只能属于一个组，因此 Cayene、BMW X5 和 Audi Q7 将属于同一组（它们的 CategoryID 将是相同的值）。
用户界面有几个下拉列表；价格区间、车类等。车类下拉列表显示不同的车类； SUV、家庭旅行车等，其中类别名称来自 CarCategory 表中的名称列。如果我像您建议的那样使用 CarCategory 表，那么实际上会有数百个类别。出于这个原因，CarCategory 表中的名称列对最终用户来说毫无用处，因为这些类别的名称会像“超级运动型 SUV”、“运动型 SUV 少一点”等。这就是为什么我想要一个类似的汽车桌也。 :)
@Ludde，将其中一个类别称为“CarType”。您刚刚描述了一对多的关系。
@JBrooks;好吧，我不同意。类别表中的名称列对于这个“类似汽车”的东西是不必要的。出于这个原因，我认为下面的雷达波布建议（SimilarCar 部分）似乎是最好的。但是欢迎你用一些例子来证明我错了。 :)