Database design 如何在单个组织关系数据库中创建多组织？

我目前有一个数据库，其中包含我们组织的供应商。这些供应商可以向我们提供各种商品（设备、用品、服务等）。就在最近，我们的组织决定将这个数据库扩展到全国各地。现在，db必须说明可以向一个或多个地点/地区供货的供应商。我面临的问题是，该供应商可以向我们的其他地点供应相同或不同的商品。目前，基本结构如下所示：

供应商 ID
名称
卖方代码

T_商品 ID
商品

T_供应商商品 ID
供应商ID
商品ID

T_供应商属性 供应商ID
PropertyID（与未显示的道具表相关）

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

--或--

我是否应该将其规范化并创建如下表：

T_供应商子公司 ID
供应商ID
卖方代码

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

这使事情正常化，并允许我在T_Suppliers表中有一个供应商与多个不同的子公司（同一家公司位于不同的地区，不同地区可能有或可能没有相同的供应商代码）。这还要求我将T_supplier商品表更改为：

T_供应商商品 ID
SSID（FK到T_供应商子公司的ID）
商品ID

---

我喜欢这样，因为它可以使事情正常化，但它需要我更改许多视图并移动数据。当然，我还需要调整我的地址表、电话表等，以说明SSID，而不仅仅是供应商ID。基本上，这使我能够让供应商“Joe’s steel”拥有三个唯一的ID（T_SupplierSubsidiary），每个ID具有一个地区属性（T_SupplierProperties），每个子公司具有一个或多个商品（T_SupplierCommodies）。我的选择中哪一个更有效，或者有更实际的解决方案？

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

---

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

你需要考虑长期影响。这是一种短期的痛苦，它会为未来返回一个更规范、更可维护的数据库吗？我的想法是，在未来几年里，快速破解可能会给你带来很多问题。例如，他们可以要求对供应商进行部门细分。如果我去规范化，那么我必须在区域Dept后面添加另一个列。这可能会继续。。。