为了防止管理分散在多个 Excel 电子表格中的产品数据的笨拙，我建立了一个 Products 数据库。
我的数据在电子表格中，因为为亚马逊和谷歌电子商务平台导出制表符分隔的文本上传文件（有点）容易。
但是我意识到我可以通过关系数据库实现同样简单的导出目标，减少不一致的麻烦，加上表达性查询语言的额外好处。
现在我的主要问题是我应该如何设计我的数据库；以及，即我的 Products 数据库应该包含多少个表。我在这里看到三个选项：
- 1 表适用于所有产品。在我看来，这会避免冗余，因此感觉是最好的选择。举个例子：如果我决定在以后向数据库添加一个属性，我就不必为每个供应商/类别这样做（请参阅选项 2 和 3）。我倾向于说有一个缺点，因为一个类别的产品在其他类别的属性中会有许多 NULL，但我不确定这是否真的是负面的。
- 每个供应商及其产品的 1 个表。这是我本能的第一选择，但我不认为这是最合乎逻辑的划分：决定产品属性独特性的关键在于它的类别，而不是从哪个供应商那里购买的。此外，即使一个供应商经常专注于某种产品，如果一个供应商销售一种以上的产品，就会出现类别重叠。
- 每种产品（例如挂锁、链条、安全设备）1 个表。我认为这是除第 1 种之外最合理的选择，因为它几乎可以保证一种产品与另一种产品需要不同的属性。我认为这种策略的明显缺点是难以进行划分。我将以安全帽为例。安全帽应该有自己的桌子吗？当然不是。（当然，除非您的业务是安全帽。）那么，向上移动类别链，建筑配件是否应该有自己的桌子？也许更近一些。安全服怎么样？这对我来说是有道理的，但是随后会出现与选项 1 相同的许多 NULL 问题，因为安全帽将与安全背心和护目镜等混为一谈。
希望我的建议不会偏离目标。在考虑我的问题之前我不想问，但我是数据库的新手，所以我确定我没有做出最明智的推理。我非常倾向于选项 1，但我很想听听任何建议，或者如果我完全错过了一个明显的策略。