<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:317462081;
mso-list-template-ids:-912220676;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">My advice for designing datamodels and working with drools is to think of it as a database and follow standard database normalization procedures.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Multiple conditions on different facts are a join between the tables.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Thomas<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> rules-users-bounces@lists.jboss.org [mailto:rules-users-bounces@lists.jboss.org]
<b>On Behalf Of </b>Wolfgang Laun<br>
<b>Sent:</b> 22 July 2011 08:06<br>
<b>To:</b> Rules Users List<br>
<b>Subject:</b> Re: [rules-users] Dynamic facts<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">On 22 July 2011 08:34, Marc Heinz <<a href="mailto:marc.heinz@no-log.org">marc.heinz@no-log.org</a>> wrote:<o:p></o:p></p>
<div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<p class="MsoNormal">> On 19 July 2011 13:42, Marc Heinz <<a href="mailto:marc.heinz@no-log.org">marc.heinz@no-log.org</a>> wrote:<br>
>> So, despite I have only updated one attribute of the fact (the age of a<br>
>> Person), all rules have been fired again, even if they had nothing to do<br>
>> with the said attribute, which could possibly produce a huge overhead.<br>
>><br>
>> I maybe misunderstood some basic concept here... But is there a way to<br>
>> prevent that?<br>
>><br>
><br>
> Reevaluation of all patterns referring to the type of a fact/object that<br>
> has been changed is a fundamental principle of production rule systems.<br>
<br>
Ok, if I have well understood, my first assumption that I was trying to<br>
explain still holds: we should minimize dependencies between rules and<br>
fields from a single fact in order to have a finer granularity for<br>
updates... Which could effectively requires to dispatch a POJO internal<br>
structure into several other facts.<o:p></o:p></p>
</blockquote>
<div>
<p class="MsoNormal"><br>
I would not accept this as a design principle for Drools or similar RBS. Three<br>
reasons:<o:p></o:p></p>
<ol start="1" type="1">
<li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1">
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".<o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1">
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.<o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1">
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. <o:p></o:p></li></ol>
<p class="MsoNormal">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...<br>
<br>
Cheers<br>
-W<br>
<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<p class="MsoNormal"><br>
Actually we were considering doing exactly the opposite in a first time:<br>
using enclosing classes extensively in order to make easier to provide<br>
some kind of structural constraint on the content of the knowledge base<br>
(such as: each values of this set should appears at most once in the<br>
knowledge base at any give time), but this is probably better done using<br>
the working memory in "equality mode" with custom equals methods.<br>
<br>
Thank you again for these precision :)<br>
<br>
Cheers,<br>
Marc<br>
_______________________________________________<br>
rules-users mailing list<br>
<a href="mailto:rules-users@lists.jboss.org">rules-users@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/rules-users" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-users</a><o:p></o:p></p>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<br>
<hr>
<font face="Arial" color="Gray" size="1"><br>
**************************************************************************************<br>
This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the postmaster@nds.com and delete it from your system as well as any copies. The content of e-mails as well as traffic data
may be monitored by NDS for employment and security purposes. To protect the environment please do not print this e-mail unless necessary.<br>
<br>
NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18 4EX, United Kingdom. A company registered in England and Wales. Registered no. 3080780. VAT no. GB 603 8808 40-00<br>
**************************************************************************************<br>
</font>
</body>
</html>