There may be a third answer to the RDBS / RBS integration question, or at least we
are attempting it. One of our problems is rollup state, where the state of an
object is dependant on the state of all its children, each of those objects is
dependant upon the state of their children......etc. What we really had was not so
much a parent/child graph as a network of interrelated objects, sort of a business
eco-system where events can have a ripple effect up and down the supply chain in
unxepected ways. Because the relationships where between heterogenious objects,
what hurt most was the number discreet queries required......
...... The architecture was Weblogic/Enterprise Java Beans under the hood with
container managed persistence to an Oracle database. Orignally we got a little
carried away with bean-dom, so that it took a really huge number of objects and the
performance was (ahem) not keeping up with the number of transactions received.
The solution had two parts:
Part one was to use the Toplink product, which plugs into Weblogic to manage bean
persistence. It can map an object to multiple tables, joins, etc, and let us create
objects that were more "natural objects" instead of attempting to match a normalized
database schema. That allowed us to cut drastically down on the number of objects,
and with the EJB/Toplink caching mechanism the average access time is significantly
faster than raw SQL. (depending on how you use your objects.) This is not a Toplink
commerical by the way, it is not actually my favorite product. But the concept is
good and the overall performance gain was a project saver.
Part two was to create and store a graph (as a single object) that represents the
current state and critical attributes of the objects participanting in a logical
"transaction". Yes, this is a small amount of data duplication. But following the
guidline that less than 10% of the data considered by the rules engine should change
very often, there is not a lot of issue with keeping the two data representations in
synch. When an event is received, the graph is obtained and loaded into the rules
engine. The rules engine makes notification to the objects represented in the graph,
if and only if the rules engine determines that they have some work to do. The
graph has navigation methods that greatly simplify the rules.
Frankly, we're still implementing and not real opinionated about the trade-offs yet.
I'd be very interested in your opinions and experiences.
[EMAIL PROTECTED] wrote:
> I've seen the recommendations on when to use a rule base system (RBS) (re.
> thread "JESS: Need of a Rule Based System!!!" started by Sachin and the thread
> "JESS: Data constraint management " started by Robert Quillen.) I wonder,
> though, about when you have a REALLY big system. I am now working on a project
> for a time and attendance system. I can imagine it handling ten to twenty
> thousand employees. (So that would be ten to twenty thousand facts.) The rules
> to pay these individuals are very complex (on the order of hundreds of rules).
> Each employee would have two to six "clocking events" per day. (That would
> potentially be six times twenty thousand more facts.) There can be ten to a
> hundred different people adding/changing facts at any given time.
>
> So I'd like to use an RBS, but can it handle it? I can't imagine keeping all
> that data in memory. So how efficient would the engine be at
> reading/representing this information in an SQL table? I've seen Thomas
> Barkenow's RDBS extension. It basically is wrapper for creating individual
> SELECT statements for each rule to find it's facts. But I can't imagine that is
> very efficient. It gets the job done, but it would be murder for a large
> system. I can see a case where it would use two SELECT statements instead of
> using a JOIN.
>
> How efficient are these RBS when there is a large number of facts being
> added/changed? What would happen if power was suddenly lost. Would anything
> get lost? (That would be a bad thing, especially since we are dealing with
> people's pay!) How would it recover?
>
> In the case of JESS, how thread safe is it?
>
> -Chuck.
>
> ---------------------------------------------------------------------
> To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
> in the BODY of a message to [EMAIL PROTECTED], NOT to the
> list (use your own address!) List problems? Notify [EMAIL PROTECTED]
> ---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
in the BODY of a message to [EMAIL PROTECTED], NOT to the
list (use your own address!) List problems? Notify [EMAIL PROTECTED]
---------------------------------------------------------------------
