多对多关系

Question

我有一个客户和经理，两个表独立。我的客户表有近1亿条记录，而经理表有100条记录。现在我有能力将客户映射到经理。规则如下

1. 一位经理可以有多个客户。
2. 一个客户可能与多个经理映射。

什么是最好的DB设计来解决这个问题？创建能够ManagerCustomerMapping是一个想法。但我对此不满意。因为这导致了我一个非常大的桌子。例如。如果Manager1和Manager2与所有客户进行了映射，则此表有2亿条记录。

Answer 1

最好的数据库设计，尽管你的疑虑，正是你所描述的。换句话说，有一个映射表ManagerCustomerMapping。

总是从3NF开始，修改当且仅当存在无法用其他方式解决的实际性能问题时。

如果您的业务规模与其看起来一样大（拥有1亿用户），磁盘存储不应该是一个问题，适当的映射表索引应该可以缓解任何性能问题。

是的，如果每个客户映射到两个不同的经理，你将有2亿条记录。这不是问题。在我工作的那些商店（System z上的DB2）上，这是关于一个中等大小的表。

SQL的美妙之处在于，如果性能不够好，您大都可以换出一个DBMS。

对于平均数据库来说，两亿行两列ID列不会很繁琐，而且这是最佳途径，尤其是如果有可能客户不可能分配给经理（或恶意反之亦然）。任何其他尝试将客户ID放入管理器表（或管理员ID放入客户表）的解决方案都会浪费空间。

Answer 2

你的号码非常有趣。客户经理有多少客户可以知道 - 100？你有多少管理人员，1M？销售人员会更好地描述吗？如果是这样，也许你应该考虑数据仓库（DW）的方法，例如金博尔明星会是什么样子：

TABLE dimCustomer (KeyCustomer, Name, Address, ...etc) 
TABLE dimSalesPerson (KeySalesPeson, Name, Phone, Area, ...etc) 
TABLE dimProduct (KeyProduct, Description, CatalogPrice, ...etc) 
TABLE dimDate (KeyDate, FullDate, Year, Month, DayOfWeek, IsHoliday, etc...) 
TABLE factSales (KeyCustomer, KeyProduct, KeySalesPerson, KeyDate, Quantity, Ammount, OrderID, ..) 

的factSales表将抓住销售的每个项目，固然大表的，但你不会需要将客户映射到经理，只需搜索事实表并找到最后一位与客户联系的销售人员。不知何故，我认为这可能更接近商业模式。
如果这不是秘密，那么这个数据库跟踪是什么类型的业务？

Answer 3

现在坚持下去。你说经理可能被分配给所有的客户？一位经理可能会负责一亿个客户？老实说，这听起来有点不对劲。

如果您有一个简单的经理< - >所描述的客户关系，那么您描述的设计（多对多链接表）是正确的。但是如果你真的希望能够把所有的顾客连接到几个管理者，我猜测你有没有告诉我们管理者的层次结构 - 也就是说，管理者可以管理其他管理者，谁可以管理其他管理人员，然后管理客户（增加可能的级别并直接管理顾客与任何级别管理人员的管理）。

你在多层次的营销组织和某些行业的佣金系统中看到了这种结构（我偶然碰巧碰到它在保险中）。

如果是这种情况，您需要分别表示管理者之间的关系（或者在管理者表中使用自引用列，如果每个管理者只有一个直接父代管理者可能，或者如果它是许多到很多），只将客户与其最终的直接经理联系起来。