因此,您真正的问题是如何快速将交易与潜在规则进行匹配。您可以使用反向索引来完成此操作,该索引说明哪些规则与属性的特定值匹配。例如,假设你有这三个规则:
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