设计 Products 数据库：一个 Products 表还是由供应商分隔的多个表？

Question

为了防止管理分散在多个 Excel 电子表格中的产品数据的笨拙，我建立了一个 Products 数据库。

我的数据在电子表格中，因为为亚马逊和谷歌电子商务平台导出制表符分隔的文本上传文件（有点）容易。

但是我意识到我可以通过关系数据库实现同样简单的导出目标，减少不一致的麻烦，加上表达性查询语言的额外好处。

现在我的主要问题是我应该如何设计我的数据库；以及，即我的 Products 数据库应该包含多少个表。我在这里看到三个选项：

1 表适用于所有产品。在我看来，这会避免冗余，因此感觉是最好的选择。举个例子：如果我决定在以后向数据库添加一个属性，我就不必为每个供应商/类别这样做（请参阅选项 2 和 3）。我倾向于说有一个缺点，因为一个类别的产品在其他类别的属性中会有许多 NULL，但我不确定这是否真的是负面的。
每个供应商及其产品的 1 个表。这是我本能的第一选择，但我不认为这是最合乎逻辑的划分：决定产品属性独特性的关键在于它的类别，而不是从哪个供应商那里购买的。此外，即使一个供应商经常专注于某种产品，如果一个供应商销售一种以上的产品，就会出现类别重叠。
每种产品（例如挂锁、链条、安全设备）1 个表。我认为这是除第 1 种之外最合理的选择，因为它几乎可以保证一种产品与另一种产品需要不同的属性。我认为这种策略的明显缺点是难以进行划分。我将以安全帽为例。安全帽应该有自己的桌子吗？当然不是。（当然，除非您的业务是安全帽。）那么，向上移动类别链，建筑配件是否应该有自己的桌子？也许更近一些。安全服怎么样？这对我来说是有道理的，但是随后会出现与选项 1 相同的许多 NULL 问题，因为安全帽将与安全背心和护目镜等混为一谈。

希望我的建议不会偏离目标。在考虑我的问题之前我不想问，但我是数据库的新手，所以我确定我没有做出最明智的推理。我非常倾向于选项 1，但我很想听听任何建议，或者如果我完全错过了一个明显的策略。

Answer 1

我会选择 1。当尝试运行需要来自多个产品表的数据的报告时，为每个供应商或每个产品类型拥有一个单独的表将是一场噩梦。您不希望每次添加供应商或产品类型时都必须创建一个新表。我了解您对电子表格的偏好，但由于能够轻松查询记录，因此将产品分成多个表并不是要走的路。

我倾向于说有一个缺点，因为一个类别的产品在其他类别的属性中会有很多 NULL，但我不确定这是否真的是负面的。

为防止这种情况，属性应位于单独的表中。

例如，部分表定义可能如下：

products
-- id
-- name

product_attributes 
--product_id
--name
--value

attributes.product_id 是 products.id 的外键。

为了进一步规范它，您可以在单独的表中定义属性并使用 attribute_id 字段而不是 attribute_name：

    attributes
    --id
    --name

    product_attributes 
    --attribute_id (foreign key of attributes.id)
    --value

（针对拼写进行了编辑）