Database design 多对多关系

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

一个经理可以有多个客户

一个客户可能与多个经理对应

---

解决这个问题的最佳DB设计是什么？创建可管理的映射是一个想法。但我对此并不满意。正因为如此，我才有了一张很大的桌子。例如如果Manager1和Manager2映射到所有客户，则此表有2亿条记录。

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

ManagerCustomerMapping

始终从3NF开始，当且仅当存在无法通过其他方式解决的实际性能问题时才进行修改

如果您的业务和看上去一样大（有1亿客户），那么磁盘存储应该不是问题，映射表的适当索引应该可以缓解任何性能问题

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

SQL的美妙之处在于，如果DBMS的性能不够好，您可以将其替换掉

---

两亿行的两个ID列对普通数据库来说并不繁重，这是最好的方法，特别是如果客户可能没有分配给经理（反之亦然）。在这种情况下，任何试图将客户ID放入manager表（或将经理ID放入customer表）的其他解决方案都会浪费空间。

您的数字非常有趣。一个客户经理能认识多少客户——100？你有多少个经理，100万？销售人员是更好的描述吗？如果是这样，也许你应该考虑数据仓库（DW）的方法，例如KimBar明星看起来像：

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

表将捕获每种商品的销售额，诚然，这是一个很大的表，但您根本不需要将客户映射到经理，只需搜索事实表并找到与客户有联系的最后一位销售人员。不知何故，我认为这可能更接近商业模式。

---

如果这不是秘密，那么数据库跟踪是什么业务

等一下。您是否声明可能会为所有客户指派一名经理？一个经理可能要为一亿客户负责？老实说，听起来好像有什么不对劲

如果您有一个简单的经理-客户关系（如上所述），那么您描述的设计（多对多链接表）是正确的。但是如果你真的想把所有的客户和几个经理联系起来，我猜有一个你没有告诉过我们的经理阶层——也就是说，一个经理可以管理其他经理，谁可以管理其他经理，然后谁来管理客户（可能有额外的级别，直接管理客户与任何级别的经理管理相结合）

你可以在多层次的营销组织和某些行业的佣金制度中看到这种结构（前几天我碰巧在保险业遇到）

---

如果是这种情况，则需要分别表示管理者之间的关系（如果每个管理者只有一个直接父管理者，则在管理者表中使用自引用列，如果是多对多，则使用单独的表）并且只将客户链接到他们的最终直接经理。

您能解释一下您希望模式解决哪种查询吗？您能更详细地解释一下经理和客户之间的关系吗？具体来说，为什么客户会有2个以上的经理？对于多对多关系，可移植SQL并不是最有效的方法。IMH两张桌子的解决方案不仅会浪费空间，而且会阻止表达多对多关系。回答好，帕克斯。