我正在更新我们网站的产品数据库。它内置于 MySQL 中，但这更像是一个通用的数据库设计模式问题。
我打算切换到超类型/子类型模式。我们当前/以前的数据库主要是单个表，其中包含有关单一类型产品的数据。我们正在考虑扩大我们的产品范围以包括不同的产品。
这个新的设计稿是这样的：
Product product_[type] product_attribute_[name]
---------------- ---------------- ----------------------------
part_number (PK) part_number (FK) attributeId (PK)
UPC specific_attr1 (FK) attribute_name
price specific_attr2 (FK)
... ...
我有一个关于产品属性表的问题。这里的想法是产品可以具有给定属性的列表，例如颜色：红色、绿色、蓝色或材料：塑料、木材、铬、铝等。
此列表将存储在表中，该属性项的主键 (PK) 将在特定产品表中用作外键 (FK)。
（Martin Fowler 的著作Patterns of Enterprise Application Architecture称之为“外键映射”）
这允许网站界面拉取给定属性类型的属性列表，并在下拉选择菜单或其他一些 UI 元素中将其吐出。该列表可以被认为是属性值的“授权”列表。
拉动特定产品时最终发生的连接数量对我来说似乎过多。您必须将每个产品属性表连接到产品，以便您可以获取该属性的字段。通常，该字段可能只是名称的字符串 (varchar)。
这种设计模式最终会创建大量表，并且您最终会为每个属性创建一个表。抵消这种情况的一个想法是为所有产品属性创建一个更像是“抓包”表的东西。像这样的东西：
product_attribute
----------------
attributeId (PK)
name
field_name
这样，您的表可能如下所示：
1 red color
2 blue color
3 chrome material
4 plastic material
5 yellow color
6 x-large size
这可以帮助减少表蠕变，但它不会减少连接的数量，而且将这么多不同类型组合到一个表中感觉有点错误。但是你可以很容易地获得所有可用的“颜色”属性。
但是，可能有一个属性具有比“名称”更多的字段，例如颜色的 RGB 值。这将要求该特定属性可能具有另一个表或具有用于名称：值对的单个字段（这有其自身的缺点）。
我能想到的最后一种设计模式是将实际属性值存储在特定产品表中，根本没有“属性表”。像这样的东西：
Product product_[type] …