In the interest of exploration and education, here's a few random thoughts.
The approach wolfgang mentions is an old knowledge base technique. I
like to use it for data that is constant-like. Things like code
reference tables. One example of this is auto insurance rating. Many
companies rate
I found this book (Giarratanno Riley) to be of very low value for my
purposes. I have yet to find a decent book about rule base programming. Jess
In Action is the only one that's been useful for me. A couple of Drools books
I've read were ridiculous. Most AI and knowledge base books are 95%
All the pundits advocate to put the decision logic into the LHS. Opinions
vary a little wrt. to the use of static facts to
reduce the number of rules. Some say, The more rules the merrier. I feel
that using static facts for lookup of data is justified, considering this:
- Fact data is easier
Thanks for the help guys. Here is what I ended up with. This works, but
I'm sure it's not the most efficient way to solve the problem.
(defrule setCalculatedCostGCI20k5k
(HrBenefitJoin (hrBenefitConfigId 1-76)(benefitJoinId
?bjid)(calculatedCost ?cost)(OBJECT
Although most folks won't complain, my only comment here is that the logic is
all contained in the action side (RHS) of the rule in the form of if-then-else
statements (basic Java) followed by more if-then-else (more basic Java)
statements. This is basically procedural code put into a rulebase
So many if else statements on the RHS is unruly.
On Jan 7, 2011, at 9:15 AM, Derek Adams wrote:
Thanks for the help guys. Here is what I ended up with. This works, but I'm
sure it's not the most efficient way to solve the problem.
(defrule setCalculatedCostGCI20k5k
(HrBenefitJoin
Hi Derek,
OK OK... I wasn't going to say anything either but with Peter and James
added to Wolfgang, I have to pile too :-)
IMHO there are a number of maxims of rule-based programming that you're
breaking here. Ernest has put the first one most succinctly in the past:
Use many smaller rules
: JESS: Re: calculating benefit costs
I couldn't agree more with james and donald.
Having a ton of if/then/else statements in the RHS really should be
avoided. One of the benefits of using a rule-centric approach is it
helps you see the logic. I find that having deeply nested if/then/else
often
