My advice for designing datamodels and working with drools is to think of it as a database and follow standard database normalization procedures.

Essentially drools in an in memory database which has a custom query and trigger syntax implemented in a very efficient manner! Each Object type is a table and each fact is a row in that table.

Multiple conditions on different facts are a join between the tables.

You wouldn’t (generally) embed lists of addresses within the person table in the database, instead you’d have two separate tables for them as this makes updates and querying much more efficient.

Generally with drools the only time you should be using the ‘from’ keyword or navigating through to child objects (person.homeAddress) is to write rules to extract those objects out and insert them as actual working memory facts.

Thomas

From: rules-users-bounces@lists.jboss.org [mailto:rules-users-bounces@lists.jboss.org] On Behalf Of Wolfgang Laun
Sent: 22 July 2011 08:06
To: Rules Users List
Subject: Re: [rules-users] Dynamic facts

On 22 July 2011 08:34, Marc Heinz <marc.heinz@no-log.org> wrote:

> On 19 July 2011 13:42, Marc Heinz <marc.heinz@no-log.org> wrote:
>> So, despite I have only updated one attribute of the fact (the age of a
>> Person), all rules have been fired again, even if they had nothing to do
>> with the said attribute, which could possibly produce a huge overhead.
>>
>> I maybe misunderstood some basic concept here... But is there a way to
>> prevent that?
>>
>
> Reevaluation of all patterns referring to the type of a fact/object that
> has been changed is a fundamental principle of production rule systems.

Ok, if I have well understood, my first assumption that I was trying to
explain still holds: we should minimize dependencies between rules and
fields from a single fact in order to have a finer granularity for
updates... Which could effectively requires to dispatch a POJO internal
structure into several other facts.

I would not accept this as a design principle for Drools or similar RBS. Three
reasons:

Drools (and its likes) have been built to cope with bean style objects, as the title of the classic paper puts it: "Rete: A Fast Algorithm for the Many Pattern/Many Object Pattern Match Problem".
Splitting "natural" objects into "facets" with a small number of fields creates the necessity of adding properties for connecting these facts and using additional contstraints for combining them in rules. The cure might be worse than the (suspected) ailment.
Design should not squint at implementation issues of the underlying system; it should orientate itself on a model that represents the problem well. It could be that you haven't chosen the right platform for your application - but then you won't improve matters by jeopardizing your design.

OK, that wraps it up. I assume that you'll continue as you have indicated. It might be interesting to hear about your experiences later on...

Cheers
-W

Actually we were considering doing exactly the opposite in a first time:
using enclosing classes extensively in order to make easier to provide
some kind of structural constraint on the content of the knowledge base
(such as: each values of this set should appears at most once in the
knowledge base at any give time), but this is probably better done using
the working memory in "equality mode" with custom equals methods.

Thank you again for these precision :)

Cheers,
Marc
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users