因此,您真正的問題是如何快速將交易與潛在規則進行匹配。您可以使用反向索引來完成此操作,該索引說明哪些規則與屬性的特定值匹配。例如,假設你有這三個規則:
Rule 1: if Country = "USA" and State = "FL"
S1 gets 100%
Rule 2: if Country = "USA" and (State = "CO" or ZIP = 78640)
S2 gets 60%
S3 gets 40%
Rule 3: if Country = "UK"
S3 gets 70%
S2 gets 30%
現在,你處理你的規則,創建這樣的輸出:
Country,USA,Rule1
State,FL,Rule1
Country,USA,Rule2
State,CO,Rule2
ZIP,78640,Rule2
Country,UK,Rule3
然後,您可以處理該輸出(或者你可以做到這一點,而你正在處理規則)並建立三個表格。一個將國家/地區值映射到規則,一個將州值映射到規則,另一個將ZIP值映射到規則。你最終的東西,如:
Countries:
USA, {Rule1, Rule2}
UK, {Rule3}
States:
FL, {Rule1}
CO, {Rule2}
"*", {Rule3}
ZIP:
78640, {Rule2}
"*", {Rule1, Rule3}
的「*」值是「不關心」,這將匹配沒有具體提及領域的所有規則。這是否需要取決於您如何構建規則。
上述索引是在您的規則發生變化時構建的。有了4000條規則,它不應該花費任何時間,並且列表大小不應該很大。
現在,如果交易的國家/地區值爲「美國」,則可以查看國家/地區表以查找提及該國家/地區的所有規則。打電話給名單Country_Rules
。對州和郵政編碼做同樣的事情。
然後你可以做一個列表交集。即,建立另一個名爲Country_And_State_Rules
的列表,其中只包含Country_Rules
和State_Rules
列表中存在的那些規則。這通常是一小組可能的規則。然後,您可以根據需要一一檢查國家,州和郵政編碼。
你正在建造的東西基本上是規則的搜索引擎。它可以讓你迅速將候選人從4,000人縮小到少數。
有幾個問題需要解決。具有條件邏輯(「OR」)使事情變得複雜一點,但它不是棘手的。此外,你必須確定如何處理歧義(如果兩個規則匹配呢?)。或者,如果沒有規則與特定的國家和州相匹配,那麼您必須備份並檢查僅與國家匹配的規則......或只匹配國家。這就是「不關心」的地方。
如果您的規則足夠明確,那麼在絕大多數情況下,您應該能夠快速選擇相關規則。有些案例會要求您爲某些交易搜索許多不同的規則。但這些案例應該很少。如果他們頻繁,那麼你需要考慮重新檢查你的規則集。
一旦您知道哪個規則適用於特定的交易,您可以輕鬆查找哪個銷售員獲得了多少,因爲比例與規則一起存儲。
你能粗略估計交易數量,銷售代表和規則嗎?對於3個規則和1M個事務有效的算法對於1000個規則和2000個事務可能是可怕的。 – ugoren 2012-01-02 19:57:04
交易記錄將約爲1500萬美元。規則將在〜4000.Salesreps表中將包含~50000 – Rohan 2012-01-02 20:13:14
您的數據格式並不完全清楚。在Salesreps記錄中,您說Attribute1是一個intValue,但在Transaction記錄和規則中,Attribute1顯然是一個字符串。此外,有多少屬性?您的交易記錄和銷售記錄顯示兩項,但您的示例規則顯示三項。另外,您的示例規則中的「salesrep1」與SalesrepId == 001相同嗎?從迄今爲止告訴我們的情況來看,沒有足夠的信息,而且有太多的含糊之處讓你得到很好的答案。 – 2012-01-02 20:19:00