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

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列表，其中24条记录中有4个项目将具有参考ID）。

您认为哪一个最好？为什么！

Answer 1

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

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

• 纸张尺寸
• 纸张重量
• 纸张模式
• 纸张类型

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

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

或者，如果它们只能以某些组合形式存在，那么就需要一个关系表来捕获/管理那些有效组合。 但是，这四个纸质“属性”仍然是关系表的外键独立表。 有些人会在该关系表上放置一个单独的ID字段，以通过单个值唯一地标识组合。 就个人而言，除非有诸如复制（或其他过程/功能）之类的技术要求，要求每个表都具有一个单字段键，否则我不会这样做。 取而代之的是，我只是从指向那些纸张“属性”查找表的四个ID字段中选出PK。 然后，这四个字段仍将进入任何基于纸张的实体。 到那时，主要纸质实体表的外观将与没有关系表时的外观大致相同，不同之处在于，不是每个纸质“属性”都有4个FK，每个ID字段都是一个ID字段表中，将有一个FK，由4个ID字段指向关系表的PK。

为什么不把所有东西都塞进一张桌子呢？ 因为：

• 它违反了使用关系数据库管理系统将数据展平为非关系结构的目的。
• 随着时间的推移，发展这种结构变得更加困难
• 它使查找特定属性的所有纸质实体变得笨拙
• 这会使查找特定属性的所有纸质实体变慢/效率降低
• 也许还有其他原因？

编辑：
关于我在撰写本文时没有出现的新信息（例如发票表等），应通过可捕获这些组合的产品/库存表进行抽象。 这就是我所指的主要纸张实体。 发票表将仅引用ProductID / InventoryID（仅作为示例），而Product / Inventory表将具有这些纸张属性ID。 我看不到为什么这些属性会出现在发票表中。

编辑2：
关于“属性”查找表的ID，不应对其进行自动递增的原因之一是，其值应取自应用程序层中的Enums。 这些查询表只是提供“数据字典”的一种方式，以便数据库层可以洞悉这些值的含义。