Sql 产品线、类别、制造商、相关软件、产品属性等的产品数据库设计

我正在为中型产品数据库重新开发前端和数据库，以便它能够支持类别/子类别、产品线、制造商、支持的软件和产品属性。现在只有一个产品表。将有按行、按类别/子类别、按制造商、按支持的软件（可选）列出的产品页面。每个页面将根据其他分类进行额外筛选

类别/子类别（多级） 产品和产品线可以指定给多个类别树。应支持多达5层的深度

产品线（单级） 产品组。产品只能在单个产品线中

制造商（单级） 产品和产品线可以分配给单个制造商

支持的软件（单级） 某些产品只能与一个或多个软件一起使用，因此可以将一个产品/生产线分配给一个或多个软件

属性（类型/选项-可以进行处理，使每种类型都是一个类别，项目都是子项） 产品和产品线可以指定属性（例如-颜色>红色/蓝色/绿色）。属性应该能够分配给一个或多个类别

由于所有这些项目基本上都是子类别的类型，我是将它们放在一个主表中，还是将它们拆分为单独的表

主表理念：

分类类型（产品线、类别/子类、制造商、软件、属性均为类型）
-TypeID
-名称

分类
-ClassID
-TypeID
-ParentClassID
-名称

分类产品协会
-ProductID
-ClassID

我仍然需要至少一个表来将类型链接在一起（例如-将属性链接到一个类别），以及一种将产品线链接到各种类型的方法

如果我为每种类型使用一个表，它可能会很快变得混乱，我仍然需要一种方法将所有内容链接在一起

多表设置：

类别
-类别ID
-名称
-父类别ID

分类关联
-类别ID
-ProductID
-ProductLineID

属性
-AttributeID
-名称
-ParentAttributeID（使用此选项，因为父项为“颜色”，子项为“红色”）

属性关联
-AttributeID
-ProductID
-CategoryID（我是否还需要将类别链接到父属性？）

兼容软件
-SoftwareID
-名称

可兼容的FTWAREASSOCIATIONS
-SoftwareID
-ProductID
-ProductLineID

制造商
-制造商ID
-名称

产品线
-ProductLineID
-制造商ID
-名称

产品
-ProductID
-ProductLineID
-制造商ID
-名称

关联的另一个选项是使用单个关联表链接上面的表：

大师协会
-ProductID
-ProductLineID
-制造商ID
-类别ID
-SoftwareID
-AttributeID

---

什么是最好的解决方案？

对于多个表，在我看来，它使设计更加明显和可扩展。虽然它现在可能适合您的解决方案，但进一步的更改可能会更加困难。

我同意Paddy。它让你将来的生活更轻松，你也更灵活。你可能想把库存控制和其他东西。要将所有内容链接在一起，请使用表的id（整数）父/子

我认为多个表格是可行的方法，但要真正了解这一点，请这样做：充实两种方式的设计，然后抽取5-10个产品样本

在5-10产品的两种设计中填充表格

现在开始编写这两种方法的查询。您将开始看到哪个更容易编写（我打赌是单表），并且您可能会发现只有一种设计（我打赌是多表）才有效

完成后，您还没有丢失工作——您可以使用表模式向前移动，并且您的一些查询已经编写好了

---

如果您遇到一个没有意义、看起来很复杂的查询，或者类似的问题，您可以将其发布在这里并获得反馈——使用真正的代码总是得到更好的评论。

只是想发布我的决定，因为我对提供的任何答案都不满意，所以我选择回答我自己的问题

最后，我设置了一组表格：

分类类型（如：产品线、类别、制造商等）

分类（同时支持父/子邻接列表、嵌套集和物化路径，以利用它们各自的优势。我有一个SQL CTE，当数据更改时，它可以一次性填充所有字段）

分类关系（能够将产品与分类关联、将分类与其他分类关联以及将分类与其他类型关联）

---

我承认这个解决方案不是100%规范化的，但是这个设置给了我通过创建新类型来扩展的终极灵活性，而且非常强大，易于查询

扮演魔鬼代言人：如果新类型需要新的表，它的可扩展性就不强了——从长远来看，这是一场可怕的噩梦。如果我使用所有单独的表，如何轻松地将所有内容链接在一起？每个项目的关联都有单独的表，或者每个“类型”都有列的一个大关联表？@Hassan我会提出相反的观点——“一个大表”方法导致了一些非常难以调试的数据库（以我的经验）。一个有许多列的表，其中一些只适用于某些“类型”的行，是不好的数据库设计。@devlopr我会尽可能地将它分开-如果不真正了解您的需求，很难知道。这里的Caffine资源不足，很难从上面解析您的需求