多對多關係

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

現在堅持下去。你說經理可能被分配給所有的客戶？一位經理可能會負責一億個客戶？老實說，這聽起來有點不對勁。

如果您有一個簡單的經理< - >所描述的客戶關係，那麼您描述的設計（多對多鏈接表）是正確的。但是如果你真的希望能夠把所有的顧客連接到幾個管理者，我猜測你有沒有告訴我們管理者的層次結構 - 也就是說，管理者可以管理其他管理者，誰可以管理其他管理人員，然後管理客戶（增加可能的級別並直接管理顧客與任何級別管理人員的管理）。

你在多層次的營銷組織和某些行業的佣金系統中看到了這種結構（我偶然碰巧碰到它在保險中）。

如果是這種情況，您需要分別表示管理者之間的關係（或者在管理者表中使用自引用列，如果每個管理者只有一個直接父代管理者可能，或者如果它是許多到很多），只將客戶與其最終的直接經理聯繫起來。