Thanks very much.
But if for every rule, there is one algorithm or discount which means that
result has nothing related with Product's id and usage. I can't merge all
rules in one rule. At the same time, besides Product and Decision fact type,
there are more fact types.
For example:
rule 1
when
Decision()
Subscriber(gender == "male" or "female")
Service(name == "ftp" or "http")
Product(id == 1)
......
then
......
end
rule 2
when
Decision()
Subscriber(gender == "male" or "female")
Service(name == "ftp" or "http")
Product(id == 2)
......
then
......
end
.....
.....
In this scenario, if there are 1000 rules, there will be a lot of JoinNode.
But in runtime, there is only one Decision instance, one Subscriber instance
and Service instance.
If I define all data in one fact type, I think that there are not a lot of
JoinNodes.
Is there any other method?
Wolfgang Laun-2 wrote:
Well, what is the realtion between id, usage and the result that's to be
stored in a Decision or a global?
Typically, such rules could be written as
rule x
no-loop true
when
$d : Decision()
$p :Product( id == 1, $usage : usage )
then
compute/store value, depending on the formula for id == 1 (using
usage)
end
// similar rule for id == 2,3,...
If value is a straightforward function of id (and usage), then implement a
function compValue and use a single rule, e.g.:
rule x
no-loop true
when
$d : Decision()
Product( $id : id, $usage : usage)
then
modify $d value to compValue( $id, $usage )
Distinguishing all individual combinations of id and usage on the LHS
seems
excessive.
The ordering of CEs also affects execution times.
-W
On 7/20/09, nesta <nesta.fdb(a)163.com> wrote:
>
>
> In this scenario, there are 1000 products, different product has
> different
> price, besides this, the price is affected by usage. I want to use
> Product.id to match the rules.
>
> As you mentioned "The crude duplication of rules where only the constant
> to
> be matched with
> Product.id varies can, most likely, be avoided."
>
> How to avoid it in this scenario?
>
>
> Wolfgang Laun-2 wrote:
> >
> > It's difficult to suggest an optimized form for your rules 1-infinity,
> > since
> > we do not know what you want to achieve.
> >
> > The crude duplication of rules where only the constant to be matched
> with
> > Product.id varies can, most likely, be avoided.
> >
> > -W
> >
> >
> >
> > On Sun, Jul 19, 2009 at 3:15 PM, nesta <nesta.fdb(a)163.com> wrote:
> >
> >>
> >> Hi,
> >>
> >> I am a newbie in drools. There are a lot of simple rules in a
> scenario.
> >> For example
> >> rule 1
> >> when
> >> Product( id ==1, usage == 1)
> >> $decision : Decision()
> >> then
> >> $decision.setValue(1);
> >> end
> >>
> >> rule 2
> >> when Product( id ==2, usage == 1)
> >> $decision : Decision()
> >> rule 3
> >> when Product( id ==3, usage == 1)
> >> $decision : Decision()
> >> rule 4
> >> when Product( id ==4, usage == 1)
> >> $decision : Decision()
> >> rule 5
> >> when Product( id ==5, usage == 1)
> >> $decision : Decision()
> >> ......
> >>
> >> I have a Product fact whose id = 5 and usage = 1, in my first
> thinking,
> >> only
> >> rule 5 is matched, there should be not much more different between 1
> rule
> >> and a lot of rules in runtime.
> >>
> >> But the result shows that they are different. More rules will cost
> more
> >> time. If there are 1 thousand rules, some Node and Sink will execute 1
> >> thousand times.
> >>
> >> My question is how to optimize this scenario?
> >> --
> >> View this message in context:
> >>
>
http://www.nabble.com/optimization-on-a-lot-of-simple-rules-tp24556724p24...
> >> Sent from the drools - user mailing list archive at
Nabble.com.
> >>
> >> _______________________________________________
> >> rules-users mailing list
> >> rules-users(a)lists.jboss.org
> >>
https://lists.jboss.org/mailman/listinfo/rules-users
> >>
> >
> > _______________________________________________
> > rules-users mailing list
> > rules-users(a)lists.jboss.org
> >
https://lists.jboss.org/mailman/listinfo/rules-users
> >
> >
>
> --
> View this message in context:
>
http://www.nabble.com/optimization-on-a-lot-of-simple-rules-tp24556724p24...
> Sent from the drools - user mailing list archive at
Nabble.com.
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/rules-users
>
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users