MySQL - 什么时候应该使用多个表？

Question

为未来的观众编辑：除了帮助我接受的答案之外，我还发现了一些非常好的信息here 。

我有一个数据库，其中包含一个用于在网站 (RV) 上显示库存的表。它存储典型信息：年份、品牌、型号等。我最初使用 6 个额外的列来存储“特殊功能”，但我不喜欢对可以列出的选项有如此严格的限制。由于我从来没有弄乱过一个表，我的直觉是添加 24 列左右来覆盖所有内容，但我脑海中的某些东西告诉我，可能有更好的方法。那么我什么时候决定 N 列太多了？这些列中的数据通常不是唯一的。

（对不起，糟糕的图表）

当前表格设计：

-----------------------------------------------------------------------
| id | year | make | model | price | ft_1 | ft_2 | ft_3 | ft_4 | ft_5 |
-----------------------------------------------------------------------
|    |      |      |       |       |      |      |      |      |      |
-----------------------------------------------------------------------

可能更好的设计：

table #1
------------------------------------
| id | year | make | model | price |
------------------------------------
|    |      |      |       |       |
------------------------------------

table #2
---------------------------------------------
| unique_id(?) |     feature     | unit_ref |
---------------------------------------------
|       0      | "Diesel Pusher" |  2,6,14  |
---------------------------------------------

我觉得第二个表格的好处可能是我可以更轻松地传播包含所有先前输入的功能的下拉列表，以加快向库存添加新单位。

这是正确的方法吗，还是我应该添加更多列并满足？

谢谢。

Answer 1

信不信由你，最好的选择可能是添加一个第三个​​表。

由于您的rvs表中的每条记录都可以链接到features表中的多行，并且每个feature可以对应多个rvs，你有一个多对多的关系，这在关系 dbms 中本质上是难以维护的。通过添加第三个“交集”表，您可以将其转换为可以由 dbms 以声明方式强制执行的一对多对一关系。

你的表结构会变成这样的

rvs
------------------------------------
| id | year | make | model | price |
------------------------------------
|    |      |      |       |       |
------------------------------------

features
--------------------------
| id   |     feature     |
--------------------------
| 1192 | "Diesel Pusher" |
--------------------------

rv_features
----------------------
| rv_id | feature_id |
----------------------
|       |            |
----------------------

你如何利用它？假设您要记录 2016 Travelmore CampMaster 有一台 25kW 柴油发电机的事实。您将首先向rvs 添加一条记录

--------------------------------------------------
| id   | year | make       | model      | price  |
--------------------------------------------------
| 0231 | 2016 | Travelmore | CampMaster | 750000 |
| 2101 | 2016 | Travelmore | Domestant  | 650000 |
--------------------------------------------------

（注意id列中的值是完全任意的；它的唯一目的是作为唯一标识记录的主键。它可以编码有意义的信息，但它必须是在它识别的记录的整个生命周期内不会改变的东西。）

然后您在features 表中添加（或已经拥有）生成器：

--------------------------------
| id   |     feature           |
--------------------------------
| 1192 | Diesel Pusher 450hp   |
| 3209 | diesel generator 25kW |
--------------------------------

最后，您将 rv 与 rv_features 中的记录相关联：

----------------------
| rv_id | feature_id |
----------------------
| 0231  | 3209       |
| 0231  | 1192       |
| 2101  | 3209       |
----------------------

（我在每个表中添加了一些其他记录作为上下文。）

现在，要检索 2016 CampMaster 的特征，您可以使用以下 SQL 查询：

SELECT r.year, r.make, r.model, f.feature
  FROM rvs r, features f, rv_features rf
  WHERE r.id = rf.rv_id
    AND rv.feature_id = f.id
    AND r.id = '2031';

得到

----------------------------------------------------------
| year | make       | model      | feature               |
----------------------------------------------------------
| 2016 | Travelmore | CampMaster | diesel generator 25kW |
| 2016 | Travelmore | CampMaster | Diesel Pusher 450hp   |
----------------------------------------------------------

要查看配备 25kW 发电机的房车，请将查询更改为

SELECT r.year, r.make, r.model, f.feature
  FROM rvs r, features f, rv_features rf
  WHERE r.id = rf.rv_id
    AND rv.feature_id = f.id
    AND f.id = '3209';

Sherantha 指向A Quick-Start Tutorial on Relational Database Design 的链接实际上看起来像是对表格设计和规范化的一个很好的介绍；您可能会发现它很有用。

Answer 2

我认为你最好熟悉关系数据库设计。 This 是我之前发现的一篇简短但很棒的文章。

Answer 3

根据您的情况，如果您不相信。功能列保持不变，则不需要第二个表。如果将来有可能随时增加功能，那么您应该将表分成两个。 （房车和功能）。然后创建第三个表来标识 RVS 和功能，因为它似乎存在多对多关系。所以我建议你使用三个表。

Answer 4

有一种叫做“第三范式”的东西，它说没有唯一 ID 的所有东西都应该是唯一的。这意味着您需要为年份制作一个表格，一个为模型制作一个表格等的表格以及一个您可以将所有这些 id 组合到一个连接数据集的表格。 但这并不总是实用的，我认为最好的方法是介于两者之间，比如经常重复的条目的表格，但不需要额外的带有唯一 ID 的价格表格，我认为这将是矫枉过正.