最好的方法避免数据库设计中的列太多和复杂

Question

库存物品：

Paper Size 
-----
A0
A1
A2 
etc

Paper Weight 
------------
80gsm
150gsm etc

Paper mode
----------
 Colour
 Bw

Paper type
-----------
 glass
 silk
 normal

Tabdividers and tabdivider Type
--------

Binding and Binding Types
--

Laminate and laminate Types
--

此类库存项目以及所有这些项目都需要存储在发票表

中

如何使用适当的RDBMS将它们存储在数据库中。

根据我对每个列表的看法，主表和JOINS检索。但是，在数据库中添加太多表可能有点复杂。

当针对发票存储所有这些信息时，这种规范化存在一些问题。这导致发票表中的列太多。

其他方式将所有这些放入一个包含更多列的表中，然后每行将是它们的组合..（黑客算法4列表中包含4个项目，超过24条记录将具有参考ID）。

你觉得哪一个最好，为什么!!

Answer 1

您最初的想法是正确的。任何声称四个表“有点复杂”和/或“太多表”的人都不应该做数据库工作。这就是RDBMS的设计（和调整）要做的事情。

这4个项目中的每一个都是某个属性的单独属性，因此它们不能简单地放入合并它们的表中。正如您所想，您从：

开始

• PAPERSIZE
• 压纸
• PaperMode
• PaperType

这些是查找表，因此应具有非自动递增的ID字段。

这些将用作主要纸质实体的外键字段。

或者如果它们只能以某种组合存在，那么就需要有一个关系表来捕获/管理这些有效组合。但是那四篇论文“属性”仍然是关系表中的外键的单独表。有些人会在该关系表上放置一个单独的ID字段，以通过单个值唯一标识该组合。就个人而言，除非有复制（或其他一些过程/功能）等技术要求要求每个表都有一个单字段密钥，否则我不会这样做。相反，我只会从指向那些纸质“属性”查找表的四个ID字段中制作PK。那么这四个领域仍然会进入任何基于纸张的实体。此时，主要纸质实体表看起来与没有关系表时的情况大致相同，不同之处在于，每个纸质“属性”都有一个，而不是每个单独的ID字段有4个FK。表，将有一个4个ID字段的FK指向关系表的PK。

为什么不将所有东西都塞进一张桌子里？这是因为：

• 它违背了使用 Relational 数据库管理系统将数据展平为非关系结构的目的。
• 随着时间的推移，这种结构越来越难以实现
• 它可以查找特定属性的所有纸质实体clunkier
• 它使得查找特定属性的所有纸质实体更慢/效率更低
• 可能是其他原因？

修改
关于我在编写上述内容时不在问题中的新信息（例如发票表等），应该通过可以捕获这些组合的产品/库存表来抽象。这就是我所说的主要纸质实体。 Invoice表只是引用ProductID / InventoryID（仅作为示例），Product / Inventory表将具有这些纸张属性ID。我不明白为什么这些属性会出现在Invoice表中。

<强> EDIT2：
关于“属性”查找表的ID，它们不应该自动递增的一个原因是它们的值应该从应用层中的枚举中获取。这些查找表只是提供“数据字典”的一种方法，因此数据库层可以深入了解这些值的含义。