Database design 需要数据库设计方面的帮助吗

假设我需要在我的产品表中存储t恤和牛仔裤。他们分享了成本、价格、数量等栏目，但腰围（仅适用于牛仔裤）和尺码（仅适用于T恤）又如何呢。我应该把它们放在一张桌子上还是分开的桌子上？如果我把它们放在一起，我会有很多空值，但是如果我把它们分开，链接它们的最好方法是什么

---

非常感谢。

您可以有一个

产品属性

表，其中腰围可能

5

，尺码可能

8

（取决于设置方式）。这还允许您在将来轻松添加新属性（甚至允许最终用户添加新属性）

然后你可以有这样的专栏

| attribute_id | value | product_id |
=====================================
| 5            | "30cm"| 28         |
=====================================

---

您可以添加一个产品属性表，这将是一个产品对多个属性

---

每个属性都有一个类型和值，这将解决您的问题：）

我将使用以下内容：

产品

ProductID INT IDENTITY,
Cost DECIMAL(4,2),
Price DECIMAL(4,2),
Quantity INT

ProductID INT,
Size INT

Jean

ProductID INT,
Waist INT

衬衫

ProductID INT IDENTITY,
Cost DECIMAL(4,2),
Price DECIMAL(4,2),
Quantity INT

ProductID INT,
Size INT

然后，可以将Jean/Shirt表上的ProductID设置为Product上ProductID列的外键

这样，您就扩展了核心产品属性，以适应更具体的产品

此外，您还可以添加更多特定的产品（新表），而不影响现有产品或产品表模式

我们目前正在实现一个类似的结构，因此我们的应用程序ORM可以支持实体的“继承”

要获得牛仔裤，您的查询将是：

SELECT Product.ProductID, Product.Cost, Product.Price, Product.Quantity, Jean.Waist
FROM Product Product
INNER JOIN Jean Jean
ON Product.ProductID = Jean.ProductID

当然，如果你正在寻找一个简单的改变，下面的答案就可以了

但这是“未来证明”您的数据库，用于将来添加产品

---

有几种方法可以解决这个问题

您已经描述了一个（其中有一堆不相关属性的空列）

RPM1984的答案表明，共享数据放在主表中，每个“类型”都有自己的额外属性表

或者，你可以按照亚历克斯和邮递员的建议

每种方法都有优点和缺点。最大的问题是RDMBSE很难在其中任何一个上强制引用完整性

在做出决定之前，认真考虑你的问题是值得的。EAV提供了最大的灵活性（您可以分配任意属性，并且永远不必更改模式），但是您最终会在应用程序层中进行大量处理。而且，您无法轻松获得包含所有属性的单个结果行

如果我非常确定我知道我需要建模的每一个“类型”，并且我将来不太可能需要创建更多的类型，我会选择类表继承

---

使用类表继承，您可以使用简单的内部联接按类型进行筛选（

select*from products-internal-join-pants

）将仅选择裤子，例如

@PostMan哈哈，我一直都是这样！但是，所有值都将存储在字符串中。你不认为它在搜索和排序方面效率不高吗？@user429147这只是一个例子。您可以将它们存储为整数。此解决方案的问题是假设所有产品属性都遵循特定的数据类型（值列）。如果有一个属性是size（很好，存储为int），那么像sizeabreviation（nvarchar，例如XXL）之类的属性呢。他需要添加更多的列（可能会破坏其他引用表/键），或者使用NVARCHAR列（MAX）或其他什么，然后存储所有数据类型并强制转换它们，这并不理想。我可以预见问题。@PostMan-来吧，伙计。=）为什么一开始就让生活变得困难？这也是我的想法。只是想确保这是最好的解决方案。谢谢。这是“泛化-专业化-关系建模”的标准答案。我觉得不错。请看下面我对@alex答案的评论。它可以工作，但只有当所有的“属性”都是相同的数据类型时，它才会工作。谢谢您的详细解释。我也更喜欢类表继承。