库存项目：
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将它们存储在数据库中。
根据我的意见，每个列表都有一个主表和JOIN检索。然而，在数据库中添加太多表可能会有点复杂。
当根据发票存储所有这些信息时，这种规范化有点问题。这导致发票表中的列太多。
另一种方法是，将所有列放在一个有更多列的表中，然后每行都是它们的组合。。（黑客算法4列表，包含24条记录中的4项，这些记录将具有参考ID）。
你认为哪一个最好，为什么！！
您最初的想法是正确的。任何声称四个表"有点复杂"和/或"表太多"的人都不应该做数据库工作。这就是RDBMS的设计（和调优）目的
这4项中的每一项都是某个事物的单独属性，因此它们不能简单地按原样放入合并它们的表中。正如你所想的，你从开始
- 纸张大小
- 纸张重量
- PaperMode
- 纸张类型
这些是查找表，因此应该具有非自动递增的ID字段。
这些字段将用作主要纸质实体的外键字段。
或者，如果它们只能以特定的组合存在，那么就需要一个关系表来捕获/管理这些有效的组合。但这四个纸面"属性"仍将是独立的表，即外键到关系表。有些人会在关系表上放一个单独的ID字段，通过一个值来唯一标识组合。就我个人而言，我不会这么做，除非有一个技术要求，比如复制（或其他流程/功能），要求每个表都有一个字段键。相反，我只会用四个ID字段来制作PK，这些字段指向那些纸质的"属性"查找表。然后，这四个领域仍将进入任何基于纸面的实体。在这一点上，主要的图纸实体表看起来与没有关系表时大致相同，不同之处在于，不是每个图纸"属性"表都有4个FK的单个ID字段，而是有一个FK，由4个ID字段组成，指向关系表的PK。
为什么不把所有东西都塞进一张桌子里呢？因为：
- 它违背了使用Relational数据库管理系统将数据扁平化为非关系结构的目的
- 随着时间的推移，这种结构更难发展
- 它使得查找特定属性的所有纸质实体变得更加笨拙
- 它使查找特定属性的所有纸张实体变得更慢/效率更低
- 也许还有其他原因
编辑：
关于我在写上述内容时不存在的新信息（例如发票表等），应该通过捕获这些组合的产品/库存表进行抽象。这就是我所说的主要论文实体。Invoice表将简单地引用ProductID/InventoryID（仅作为示例），而Product/Inventory表将具有这些纸质属性ID。我不明白为什么这些属性会出现在发票表中。
第2版：
关于"属性"查找表的ID，它们不应该自动递增的一个原因是它们的值应该取自应用层中的枚举。这些查找表只是提供"数据字典"的一种方式，这样数据库层就可以深入了解这些值的含义。