Hi!
>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.
Note that any number of records can be retrieved using that extension. You
don't need to fetch records individually. The number of facts actually
created by the framework depends on the condition implicitly stated by the
(need-schema-table) goal fact asserted during backward chaining. You could
thus define some intelligent prefetch strategies. Note that, as long as a
fact exists in the Rete network, it won't be read again from the database,
i.e., backward chaining won't occur.
The classes you've seen are a simplified excerpt from a considerably more
powerful and feature-rich framework that I've developed for system
integration and process control purposes. One important part is an observer
component that monitors database modifications (inserts, updates, deletes)
in order to infer state changes of business objects persistently stored in
that database. The first part of the problem, i.e., detecting insertions,
updates, and deletes, is done by automatically generated database triggers
that create change notifications (XML strings, to be specific). These
notifications (instances of UML SignalEvents) are automatically converted
to Jess "event" facts. Thus, you wouldn't need to pull each fact from the
database. They could also be pushed to you, if that simplifies matters.
Only "state" facts would be read from the database, e.g., in order to check
conditions of Jess ECA rules. This mode of operation can also be mixed with
a prefetch strategy.
>I can see a case where it would use two SELECT statements instead of
>using a JOIN.
Do you think that's good or bad? I've had situations where performing joins
externally was a lot faster than letting the RDBMS do it.
There doesn't need to be a one-to-one mapping from facts to tables (base
relations). You can also define database views and corresponding
deftemplates/facts.
Greetings
Thomas
________________________________
Dipl.-Inform. Thomas Barnekow
Fraunhofer IAO, Competence Center Software Technology
mail: Nobelstra�e 12, D-70569 Stuttgart,
Germany
phone: +49 (0) 711 / 970 - 2346
fax: +49 (0) 711 / 970 - 2300
mobile: +49 (0) 172 / 7126018
email: [EMAIL PROTECTED]
web: http://www.swt.iao.fhg.de
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
