Yuri, Not is a simple and cheap CE to use. In a simple analysis, the cost of NOT CE is even lower than a JOIN, since it will try joins, but will propagate a single tuple. So, go ahead, your second approach is the best way to go.
[]s Edson 2007/7/23, Yuri de Wit <[EMAIL PROTECTED]>:
I am working on a drools application with few rules and large number of facts. In my first design I tried to avoid excessive joins thinking I was helping improve performance but didnt realized that I was actually shooting myself in the foot. I was basically creating a single facade-fact that would contain two or three diff concerns joined under the same interface. The problem I am seeing is that for simple things like changing the status of one of many facts would cause that fact to be reevaluated against all the other facts. I then realized that thinking relationally about the problem would not only simplify my solution but also probably make a lot faster. However, in this new and relational solution I will need to make use of many "not" CE. My question is: is there any cost in using "not"s that I should be awae of? Any other words of wisdom re: improving the performance in small rules x many facts? thanks, -- yuri _______________________________________________ rules-users mailing list [email protected] https://lists.jboss.org/mailman/listinfo/rules-users
-- Edson Tirelli Software Engineer - JBoss Rules Core Developer Office: +55 11 3529-6000 Mobile: +55 11 9287-5646 JBoss, a division of Red Hat @ www.jboss.com
_______________________________________________ rules-users mailing list [email protected] https://lists.jboss.org/mailman/listinfo/rules-users
