创建表格设计的困惑答案

【问题标题】：Confusion in creating table design创建表格设计的困惑
【发布时间】：2014-07-31 15:19:22
【问题描述】：

我正在使用 Mysql，我有两个表-

BusDetails
    +-------+-----------+
    | busId | BusName   |
    +-------+-----------+
    | 1     | A TRAVELS |
    | 2     | B TRAVELS |
    | 3     | C TRAVELS |
    +-------+-----------+

AreaDetails
+--------+----------+
| cityId | cityName |
+--------+----------+
| 1      | ABC      |
| 2      | DEF      |
| 3      | GHI      |
| 4      | JKL      |
+--------+----------+

现在我必须创建第三个表，它将公共汽车表映射到城市表。假设 busId 1 停在 cityId 2 和 3， bustId 2 停在 cityId 1 和 4。要创建这个场景，我有 2 个选项-

first option-
+-------+--------+
| busId | areaId |
+-------+--------+
| 1     | 3,2    |
| 2     | 4,1    |
+-------+--------+

second option-
+-------+--------+
| busId | areaId |
+-------+--------+
| 1     | 2      |
| 1     | 3      |
| 2     | 1      |
| 2     | 4      |
+-------+--------+

将来当有大量记录时，哪个表会提供更好的性能？为什么？

【问题讨论】：

我认为第二个选择是面糊。由于您将在此场景中管理一对多关系。因此您可以轻松找到与公共汽车或区域相关的任何信息。
了解数据库规范化。逗号分隔的列表在关系数据库中是邪恶的。
@Barmar 那么冗余呢？如果我选择第二个选项，我会一次又一次地重复 busId。
如果每个人都描述一个独立的关系，这不是多余的。如果映射表中还有busName，那将是多余的。
这是关系数据库模型与分层和网络模型之间的区别。当你有一个多对多的关系时，你必须列出所有的对。

标签： mysql schema

【解决方案1】：

第一个选项很糟糕，因为逗号分隔的列表不会被索引。如果要查找区域 2 中的所有公共汽车，则必须使用

SELECT busID
FROM bus_areas
WHERE FIND_IN_SET('2', areaID)

这将必须执行全表扫描，解析每一行的areaID 列，并测试2 是否是结果数组的成员。

使用第二个版本，您可以：

SELECT busID
FROM bus_areas
WHERE areaID = 2

如果您在areaID 上有索引，这将非常有效。

如果您想知道每个区域有多少辆公共汽车，第二个选项很容易：

SELECT areaID, COUNT(*)
FROM bus_areas
GROUP BY areaID

第一个选项会比较麻烦：

SELECT cityID, COUNT(*)
FROM areaDetails a
JOIN bus_areas ba ON FIND_IN_SET(a.cityID, ba.areaID)
GROUP BY cityID

这将非常低效，因为它必须执行 M*N FIND_IN_SET 操作，并且正如我在上面解释的那样，它无法被索引。请注意，我必须加入 areaDetails 表，因为无法枚举 SQL 中逗号分隔列表中的所有区域。

【讨论】：

【解决方案2】：

答案取决于你的使用。

虽然不推荐第一个选项，但如果您有非常大的数据并且您不打算执行广泛的数据库操作（可能用于自己或小型项目），您可以使用它。

第二个选项有它自己的优势，并被关系模型推荐。它将为您提供更大的灵活性和可扩展性，因为这可以最大限度地减少冗余。

【讨论】：

【解决方案3】：

亲爱的第二个表是更好的所有原因，因为在很长一段时间你有大数据第二个类型来保存这么多的行，但更好地让报表更容易，因为 SQL 查询很容易。你们都可以输入 join easy。

【讨论】：