创建一个 SQL 表是否完全知道某些列（某些行）没有数据是不好的做法？

Question

我试图避免使用 EAV 模型，因为我希望属性具有适当的类型。但是我想决定是否应该为不同类型的产品创建多个属性表，还是只创建一个。

所有项目都是“产品”，所以我觉得它们属于一张桌子。但是，某些产品类型与其他产品类型不具有相同的属性。考虑以下几点：

---

Table: Product
- productID [INT]
- name [VARCHAR]
- type [FK]

Table: Product_Type
- productTypeID [INT]
- description [VARCHAR]

---

产品分为三种类型：主要产品、配件产品和供应产品。不同类型的产品共享许多属性，但不是全部。所以我想知道我是否要创建一个包含所有属性的属性表，并理解配件/用品不会使用一半的列或为每种类型的产品创建单独的属性表。

选项 #1：一个属性表

Table: Product_Attribute
- productID [FK]
- nameInternalCode [VARCHAR]
- nameExternalCode [VARCHAR]
- dateAnnouce [DATE]
- dateSell [DATE]
- serviceable [BIT]
- etc. etc. etc.

优点：前端逻辑 (PHP) 很简单，因为您只需要从一个表中选择产品属性。
缺点：虽然所有项目都是“产品”，但它们并不都具有相同的属性。因此，例如配件或耗材的行将包含永远不会包含数据的列。

这种做法被认为是不好的吗？要创建一个完全了解某些行永远不会包含某些列的数据的表？

选项 #2：两个/三个属性表

Table: Product_Main_Attribute
- productID [FK]
- nameInternalCode [VARCHAR]
- nameExternalCode [VARCHAR]
- dateAnnouce [DATE]
- dateSell [DATE]
- serviceable [BIT]
- etc. etc. etc.

Table: Product_Accessory_Attribute
- productID [FK]
- dateAnnouce [DATE]
- dateSell [DATE]
- serviceable [BIT]
- etc. (Shorter List)

Table: Product_Supply_Attribute
- productID [FK]
- serviceable [BIT]
- etc. (Shorter List)

优点：该表更好地代表了它负责的数据类型。不再有任何没有数据的列。
缺点：在前端 (PHP) 上创建额外的逻辑要求。必须首先确定是什么类型的产品才能知道从哪个表中读取属性。

Answer 1

我根据可能的使用方式来设计我的数据库。

读取重型数据库 - 倾向于更加非规范化。

加载繁重的数据库 - 倾向于高度标准化

这是一个适合工作的工具的问题。

我个人会选择第二个选项。在提出的那些中，但我会把它分解得更多。

**Products**
-ProductID
-ProductName

**Product_Main_Attribute**
-Surragate Key
- ProductUD
- nameInternalCode 
- nameExternalCode
- dateAnnouce 

**Product_Sale**
-Surragate Key
-ProductID
-DateSell

**Product_Service**
-Surragate Key
-ProductID
-Serviceable

这将使您更快地写入数据库。另一件事是，这也将有助于降低重复数据出现在数据库中的风险。

我在一个系统中工作，我们的表在 100 个中具有类似的设计结构，并且由于设计的原因，实际上由于所有内容的引用方式，数据要少得多。

快速回答您的问题。不是真的