用SQL Server建立规则引擎

我们区分机制的一个重要特征是对于每个不同的区分，区分的标准是相似的。那就是，应用相同的基本标准并稍微改变实例化值来用于不同的区分。例如，我们的查询实例返回了一个由中年男人和其它一些限制组成的区分。另一个区分则基于同样的限制，除了把男人替换为女人。简言之，用同样的标准集来创建我们所有的不同区分： · DOBBetween(c,x,y) — 如果c为真，则c的生日在x和y之间 · AvgMonthlyPurchase(c,x) — 如果c为真，则c每月的花费大于x美元 · ResState(c,x) — 如果c为真，则c居住在x州 (例如：佛罗里达) · Gender(c,x) — 如果c为真，则c的性别为x · Purchasing(c,x) —如果c为真，则c 正在购买产品x 因此，我们所有的需求都以这5个标准为基础，只不过c，x和y的值不同而已。然而一个真正的系统可能有一个非常大的标准集，但单个的区分方案不太可能包含过多的标准。原因之一是绝大多数划分方案会进一步细分为更小的区分方案。在查询方面，我们建议对于每个不同的查询，返回一个完全不同的消费者集。在前面的例子中，这是很有意义的，因为方案中包含的特征确保了只有一个产品被推荐给消费者。如果不是这种情形，我们就必须建立一个冲突解决机制，或者推荐多种产品给消费者（实际上有一个好得多的方法来向我们的消费者推荐多样的产品, 稍后我们会在这篇文章中介绍这个方法）。当然，那些后面的方法是正确的，并且他们都能立即用现在的规则引擎来实现，但他们不一定经常是好的选择。

外文原文（复印件） Building a Rule Engine with SQL Server One important feature of our partitioning mechanism is that the distinguishing criteria were similar for each of the different partitions. That is, applying the same basic criteria with slightly altered instantiation values imposed the different partitions. For example, the partition created by our example query returned only men of a certain age meeting a few other restrictions. A second partition was based on the same restrictions except that it contained only women, instead of men. In general, using the same set of criteria created all of our different partitions: · DOBBetween(c,x,y) — true if customer, c, was born between dates x and y · AvgMonthlyPurchase(c,x) — true if customer, c, spends more than x dollars per month · ResState(c,x) — true if customer, c, lives in state x (e.g. Florida) · Gender(c,x) — true if customer, c, has gender, x · Purchasing(c,x) — true if customer, c, is currently purchasing product, x So, all of our queries are based on these same five criteria, but with different values for c, x, and y. While a real system may have a much larger set of criteria, it is rather unlikely that any single partitioning scheme would be based on too vast a number of criteria. One reason for this is that most partitioning schemes would seek to impose disjoint partitions (equivalence classes). In terms of queries, we are suggesting that each different query would return a completely different set of customers. In the context of our running example, this makes sense, since the specificity implied by such a scheme ensures that only a single cross-sell product is suggested. If this were not the case, we would either have to develop a conflict resolution mechanism, or suggest multiple products to our customer (there is actually a far better way to suggest multiple products to the customer, as we will show later in this article). Of course, there is nothing wrong with these latter approaches, and they can both be easily implemented using the rule engine present shortly, but they may not always be the right choice.