如何组织单组织关系数据库？

Question

我目前有一个包含我们组织供应商的数据库。这些供应商可以为我们提供各种商品（设备，用品，服务等）。就在最近，我们的组织决定扩展该数据库，以覆盖全国其他地区。现在，数据库必须考虑可以提供给一个或多个位置/区域的供应商。我面临的问题是该供应商可以向我们的其他地方提供相同或不同的商品。目前基本结构如下：

  

T_Suppliers

     

ID
  名称
  VendorCode

     

T_Commodities

     

ID
  商品

     

T_SupplierCommodities

     

ID
  供应商ID
  商品ID

     

T_SupplierProperties

     

供应商ID
  PropertyID（这与未显示的prop表有关）

我创建的许多视图都基于此T_SupplierCommodities表，因为它为我提供了供应商及其所有商品，反之亦然。我应该只是“反规范化”并将另一个字段添加到T_Suppliers表中，该表告诉我该区域（即Region）？这当然意味着许多供应商名称将在此表中重复，唯一的区别是“区域”字段（也许他们的供应商代码在区域之间可能会有所不同。）这种方法的好处是我不这样做真的要改变我的查询，因为我真的只是添加“新”供应商。

- 或 -

我应该保持标准化并创建一个这样的表：

  

T_SupplierSubsidiaries

     

ID
  供应商ID
  VendorCode

*注意：我可以将实际区域作为此表中的字段或T_SupplierProperties表中的属性。

这使事情正常化并允许我在T_Suppliers表中有一个供应商，其中有许多不同的子公司（同一公司位于不同的地区，可能会或可能不会跨地区拥有相同的供应商代码。）这也要求我改变我的T_SupplierCommodities表到此：

  

T_SupplierCommodities

     

ID
  SSID（FK到T_SupplierSubsidiaries的ID）
  商品ID

我喜欢这样，因为它可以保持标准化，但它需要我更改许多视图并移动数据。当然，我还需要调整我的地址表，电话表等，以便考虑SSID而不仅仅是供应商ID。从本质上讲，这使我能够让供应商“Joe's steel”拥有三个唯一ID（T_SupplierSubsidiaries），每个ID都有一个region属性（T_SupplierProperties），每个子公司都有一个或多个商品（T_SupplierCommodties）。我的哪个选项更有效率，还是有更实用的解决方案？

Answer 1

这里的诀窍是要意识到商品清单不再属于供应商。相反，商品清单属于供应商+地区的交界处。

换句话说，现在必须由供应商和地区识别商品清单，而不仅仅是供应商。