Hi George,

I don't know about EJB, as we don't use them, but having an extra table to
represent an n-m relationship is a well stablished technique when designing
relational databases. AFAIK there's no other way to do that while providing
db-enforced consistency and avoiding redundancy. You represent a logical n-m
relationship, you create a new table that implements two real 1-n relationships,
thus creating one extra table. I don't see where you get two extra tables per
relationship from.
regards,
D.

George Mardale wrote:

> Hello Owen,
>
> Thank you for your kind response. Yesterday, while waiting for a response on
> the Orion mailing list, we thought of a design somehow close to yours. We
> thought that using 3 different tables (ClassRoles, GroupRoles, UserRoles)
> was a good ideea.
>
> But today, we came up with a solution that we thought would benefit of
> Orion's powerful features. Thanks to Alex Paransky who helped us a lot, we
> tried to redesign the system, using OR mapping. So, we designed something
> like this:
>
> public class GroupBean implements EntityBean
> {
>     ...
>     List users; //1..* relationship with UserBean
> }
>
> public class UserBean implements EntityBean
> {
>     ....
>     List groups; //1..* relationship with GroupBean
> }
>
> Practically, we broke every  *..* relationship (in this case Group(*) -
> User(*)) into two 1..* relationships. And so on, for every relationship that
> we have:
> Class(1) - Group(*)
> User(*) - Role(*)
> Group(*) - Role(*)
> Class(*) - Role(*)
>
> As far as I know, Orion will create an additional table in the database that
> will store the relationship. For example, for users attribute in GroupBean,
> it will create a new table Group_users, besides the existing Group and User
> tables. Practically, for every *-* relationship will have 2 more tables in
> the database. Is that correct?
>
> What I want to know is if this design is correct. Are there any drawbacks
> that would make this system work unproperly (may be some OR mapping
> problems)?
>
> Tkanks,
> George.
>
> ----- Original Message -----
> From: "Owen Fellows" <[EMAIL PROTECTED]>
> To: "Orion-Interest" <[EMAIL PROTECTED]>
> Sent: Tuesday, October 02, 2001 10:58 AM
> Subject: RE: Design strategy
>
> > Hello,
> >
> > We have done a similar thing were we don't know the type of class assign
> the
> > role except at runtime.
> >
> > The solution we used was to have an Object Type table (contain Class,
> Group,
> > User).
> > Then created a interface which was Roleable (i.e. this class can have a
> role
> > assigned).
> > In the database you can store each assignment in a different table
> > (ClassRoles, GroupRoles, UserRoles),
> > or have a generic table that stores Roleable_id, Role_id and
> Object_type_id.
> >
> > This does have drawbacks e.g. the Database does not have enforced
> > consistence as the Roleable_id is not a foreign key on any one table.  It
> > may also be slower to retrieve the Roles for a particular (Class, Group,
> > User) as you will have to lookup it object type and then its roles.  (You
> > could always cache object types as there will not be that many).
> >
> > I'm sure you can implement a Bean with the above functionality (we haven't
> > used beans for this so I can help there).
> >
> > Hope this is of some help.
> >
> > Owen
> >
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]On Behalf Of George Mardale
> > Sent: 02 October 2001 06:06
> > To: Orion-Interest
> > Subject: RE: Design strategy
> >
> >
> > Hello Alex,
> >
> > Thank you for your prompt response. Your suggestions are excellent.
> >
> > You're right, the analysis is not correct. I tried to reduce the problem
> to
> > a
> > simple example. To avoid complexity, I just limited the relationships to
> > 1..*.
> > Maybe the example is not the best, but I only wanted to know if I could
> > model
> > the "Abstract being" bean in Orion.
> >
> > There are still 2 issues we are unclear about:
> > 1. what are the advantages of dumping entity Class? (Class has specific
> > fields
> > that Group does not have)
> > 2. could you please detail the best way to implement  a *-* relationship
> in
> > Orion?
> >
> > Thanks,
> > George.
> >
> >


Reply via email to