In a project I was recently involved with, we used a variant of (2), below.
The notion of (2) and (3) is to store the many side of the relationship in
a single field in the table. However, using either a serlialized Vector
of PKs or a serialized Vector of handles is not very database friendly,
and will have poor performance.
The solution we used was to implement a conversion algorithm in the ejbStore/
ejbLoad methods, which converted the Vector to a delimited string. So,
if the vector were to contain references to A, B, and C, the string would
contain "A|B|C". Furthermore, the converstion to/from {A,B,C} and "A|B|C"
was done in a subclass bean, which over-rode the ejbStore/ejbLoad methods,
meaning that this database-friendly workaround was non-intrusive on the
Entity bean code itself. (It did show up in the CMP deployment descriptor,
however, as a string field.)
Obviously, the benefits of this approach are that (a) you are storing a
string in the database, as opposed to an unreadable serializable BLOB, and
(b) the conversion between the delimited string and the Vector is
substantially faster (as compared to using Serialization to/from a byte
array/BLOB).
-jkw
Heiko Gottschling wrote:
>
> Hi,
>
> I need to model a large number of n:m relations in my project, e.g. I have a
> class named 'Component', which contains a Vector of 'Feature' objects:
>
> public class Component {
> private Vector features;
> }
>
> I want to model the Component class as a BMP entity bean. I can think of
> three possible strategies:
>
> 1. Use a 'link' table, consisting of (componentId, featureId). However, my
> project contains a large number of different n:m relations, which would
> result in creating one link table for every Vector I use :-(
>
> 2. I could store the primary keys of the Feature entities in the Vector, and
> store a serialized version of that Vector in the database with every
> Component record. Thus, I would not need an additional table
>
> 3. Like (2), but instead of primary keys I could store entity bean handles in
> the Vector (hmmm I wonder if this is a good idea?)
>
> Variant (1) would be the traditional database approach, however I would
> prefer (2) or (3), since they are easier to handle.
>
> What do you think?
>
> thx
> Heiko
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
