I´ve benn there. Only was the problem a public administration with a lot of
levels, where each office where stored in a recursively organized table
OFFICE. They kept changing the structure of the administration so from a DB
point of view this was optimal. BUT.
We ran into to serious perfomce problems when we whanted to search the
employees of diffet offices... Hmmm first we made a OFFICE_EMPL_VIEW on the
OFFICE and EMPLOYEE table with outer joins, but performance on Oracle didn't
emprove because the preferred strategy by Oracle 8i was to conduct tablescan
of our tables -SLOWWWWWW. Today we use materialised views i Oracle, which
boots performance by factor 1500!! It is still not a satisfactory solutions
because the view has to be rebuild on every insert/update in the EMPLOYEE
table. It is done automatically, but takes a while everytime.
If you dont have access to Oracle 8i or another DB with materialized views,
I think the RMI stored tree is worth a try. It should perform OK. If you are
managing all data through EJB you can programatically keep it syncronized
with a few calls in your THING entitybean..
Sune
-----Original Message-----
From: Tom Cook [mailto:[EMAIL PROTECTED]]
Sent: Monday, February 19, 2001 12:34 AM
To: JBoss-User
Subject: Re: [jBoss-User] Recursive data structures
On Fri, 16 Feb 2001, you wrote:
> > I also fail to understand why it is a problem. How is recursive
> references
> > different to any other entity relationship? Just store a PK, a Handle,
> > whatever...
>
[snip]
> Now an example of what's been bamboozling me.
>
> Suppose the taxonomy were of species; Butterfly would be a subclass of
> Insect, which in turn subclasses Animal, likewise Organic. Consider a
> particular butterfly called Jim, represented by a row in the Thing table.
>
> We assert that Jim is a butterfly by creating a suitable row in the
> ThingCategory table. However, because Butterfly is a subcategory of Insect
> (etc), by implication Jim is a member of the classes insect, animal and
> organic. Inheritance.
>
> Certainly it is possible to materialise the categories that apply by
> implication to Jim (or any other thing) but I am somewhat at a loss to say
> how one might (efficiently) go about retrieving a set of Things that are
> members of the category Animal.
Ew, yuck, yeah, I see what the problem is. How would you express it in SQL?
Stored procedure, perhaps...
Otherwise, you'll need to construct an inheritance tree somehow. If you
*know*
that EJBs will be your only client, you could construct an RMI cache of the
inheritance tree at startup, and then access that from your bean. This
would
be foul to try to maintain if the database was being updated externally,
though.
Perhaps the best way would be to have a Category bean. The home interface
has
a create(...) method, a findByPrimaryKey(...) method, a findByName(...)
method
etc. The remote interface has probably only two methods, getSubCategories()
and getMemberThings(). Then, in a finder somewhere, you get the Category
for
the type you want, call getMemberThings() on it, add them to a Vector, then
recursively call getSubCategories(), calling getMemberThings() on each one,
and
adding them to the Vector().
I don't know how this would perform; my suspicion is that it would get
rapidly
worse as the network got more complex, and would of course not handle
circular
references and the like.
My $0.02
Tom
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
List Help?: [EMAIL PROTECTED]
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
List Help?: [EMAIL PROTECTED]
