from first hand experience and those of other seasoned rule consultants, here's the pros/cons of using decision table.
pros 1. it's easy for a non-technical user to use if they are familiar with ms office 2. it's easy if there's 2 dozen columns or less 3. the learning curve is lower 4. good fit for situations with a few rules cons 1. tables with columns that require scrolling left/right become hard to understand, even for business users. usually, this means too much business logic is being jammed into a single table when the logic should be broken into smaller pieces 2. tables with thousands of rows become difficult to understand and maintain 3. without good rule validation tools, it's easy to create invalid rules that conflict with other rows in the decision table 4. tables are poor at expressing more complex rules that require calculations or lookup code reference data Lots of people have seen situations where a decision table had tens of thousands of rows. I've personally seen cases where 50,000 rows of decision table rules could be translated to several hundred rules. The key was taking time to understand what the business wanted and making it easier to author and manage. In this particular case, I built a pre-trade compliance engine for a securities order management system. As usual, the key to building a maintainable application is taking time to understand the problem. If the application will never have more than a dozen rules with a half dozen columns, decision table is a perfectly fine solution. On Sun, Jan 9, 2011 at 10:04 PM, <debasish.da...@cognizant.com> wrote: > Hi all, > > Thanks a lot for the detail clarification of using the concept of > 'fact-data' instead of hard-coding constants inside the rule (as you have > explaned in your example, and rules in this scenario looks homogeneous, and > only difference is the hard-code constant part). > > Now, we know how to do it using JESS, and concern is with other available > rule engine vendors - how they are managing this situation, since this is > pretty much common issue in most of IT-service industry projects using > rule-engine for some business decision; and as of today, vendors are > suggesting to use Decision Table concept to handle this homogeneous type > rules. To my understanding, this is nothing but the representing of 'n' > number of homogeneous type rules with different hard-coded constant values. > > Please make my understanding correct. > > > Regards > > DEBASISH DALUI (122816) > ---------------------------------------------- > Cognizant Technology Solutions US Corp > Cell : +1-216-835-2902 > > ------------------------------ > *From:* owner-jess-us...@sandia.gov on behalf of Peter Lin > *Sent:* Sun 1/9/2011 9:33 AM > > *To:* jess-users@sandia.gov > *Subject:* Re: JESS: Re: calculating benefit costs > > 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 based on zip code and assign a numeric value for each > zip code. > > If a developer hard codes the constant in the rule, it means every > time the value changes, the rule would need to be updated. The problem > is actually worse than that. Say a company sells insurance in 5 states > and there's a total of 500 zip codes. Using the hard coded approach, > the developer would need to write 500 rules. If on the other hand, the > developer uses facts to match the insurance policy to a zip code > rating fact, we can easily change the rating value for a zipcode and > not affect the rules. > > The downside is we need to have good management tools for editing the > reference data. All of the reference data should be versioned and > basic validation should be performed on the data before it is deployed > to production. Unfortunately, all of the products on the market today > do not provide robust tools for managing knowledge base data. In the > past, I've written custom applications for managing knowledge data in > financial applications. > > For applications that have lots of code reference data that changes > regularly, I strongly recommend using fact data instead of hard coding > constants. The other benefit is tends to reduce lots of procedural > code in the RHS of the rule. Instead of using lots of if/then/else, > the rule tends to match the facts in the LHS and use the reference > data in the RHS. To put it another way, some of the calculations have > become pre-calculated codes. This can make the rules easier to read > and maintain. Also, by precalculating some of the data, we reduce the > amount of work the rule engine has to perform each time. > > Using these types of knowledge base techniques also makes it easier to > write proof and validation routines to make sure the pre-calculated > tables are accurate. I would recommend reading books on knowledge base > and expert systems to get a broader understanding of rule programming. > Most of the business rule books out there are really just user manuals > and don't go into details on the design patterns used in expert > systems. Gary Riley's book is a great place to start. > > > As wolfgang stated, > > On Sat, Jan 8, 2011 at 10:39 AM, Wolfgang Laun <wolfgang.l...@gmail.com> > wrote: > > 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 to change than rule code. > > Putting the data into facts is one way of avoiding hard coded constants
