Question

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

一位经理可以拥有多个客户。
一位客户可能会与多位经理联系。

解决此问题的最佳数据库设计是什么？创建有效的ManagerCustomerMapping是一个想法。但我对它并不满意。因为这导致我一张很大的桌子。例如。如果Manager1和Manager2映射到所有客户，那么此表有2亿条记录。

Answer 1

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

始终以3NF开头并修改当且仅当存在无法以其他方式解决的实际性能问题时。

如果您的业务规模如此之大（拥有1亿客户），那么磁盘存储应该不是问题，并且对映射表进行适当的索引可以减轻任何性能问题。

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

SQL的优点在于，如果DBMS表现不佳，你可以大部分更换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

现在坚持下去。您声明可能会将经理分配给所有客户？经理可能会对<亿> 客户负责？老实说，这听起来有些不对劲。

如果你有一个简单的经理＆lt; - ＆gt;如上所述的客户关系，那么您描述的设计（多对多链接表）是正确的。但是，如果你真的希望能够将所有客户与几位经理联系起来，我猜测你没有告诉过我们的经理层级 - 也就是说，经理可以管理其他经理，他们可以管理其他管理人员，然后管理客户（可以提供额外的级别，并将客户的直接管理与任何级别的管理人员混在一起）。

您可以在多层次营销组织中看到这种结构，也可以在某些行业的佣金系统中看到这种结构（前几天我碰巧遇到了保险）。

如果是这种情况，你需要分别表达管理者之间的关系（如果每个经理只有一个直接的父经理，或者如果有很多单独的表，则可以在经理人表中使用自引用列）许多人）只将客户与他们的终极直接经理联系起来。

多对多的关系

3 个答案: