[英]Best approach to avoid Too many columns and complexity in database design
库存物品:
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)。
您认为哪一个最好?为什么!
您最初的想法是正确的。 任何声称四个表“有点复杂”和/或“太多表”的人都不应从事数据库工作。 这就是RDBMS设计(和调整)的目的。
这4个项目中的每一个都是某物的单独属性,因此不能简单地将它们原样放入合并它们的表中。 如您所想,您首先要:
这些是查找表,因此应具有非自动递增的ID字段。
这些将用作主要纸质实体的外键字段。
或者,如果它们只能以某些组合形式存在,那么就需要一个关系表来捕获/管理那些有效组合。 但是,这四个纸质“属性”仍然是关系表的外键独立表。 有些人会在该关系表上放置一个单独的ID字段,以通过单个值唯一地标识组合。 就个人而言,除非有诸如复制(或其他过程/功能)之类的技术要求,要求每个表都具有一个单字段键,否则我不会这样做。 取而代之的是,我只是从指向那些纸张“属性”查找表的四个ID字段中选出PK。 然后,这四个字段仍将进入任何基于纸张的实体。 到那时,主要纸质实体表的外观将与没有关系表时的外观大致相同,不同之处在于,不是每个纸质“属性”都有4个FK,每个ID字段都是一个ID字段表中,将有一个FK,由4个ID字段指向关系表的PK。
为什么不把所有东西都塞进一张桌子呢? 因为:
编辑:
关于我在撰写本文时没有出现的新信息(例如发票表等),应通过可捕获这些组合的产品/库存表进行抽象。 这就是我所指的主要纸张实体。 发票表将仅引用ProductID / InventoryID(仅作为示例),而Product / Inventory表将具有这些纸张属性ID。 我看不到为什么这些属性会出现在发票表中。
编辑2:
关于“属性”查找表的ID,不应对其进行自动递增的原因之一是,其值应取自应用程序层中的Enums。 这些查询表只是提供“数据字典”的一种方式,以便数据库层可以洞悉这些值的含义。
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.