避免數據庫設計中列過多和復雜的最佳方法

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。 這些查詢表只是提供“數據字典”的一種方式，以便數據庫層可以洞悉這些值的含義。