While I agree that the 3-table approach is not necessary to do 1-M
mappings, and that there are performance reasons that make the 2-table
method attractive, the 3-table method has the benefit that it doesn't
allow the fact that the object in the M (many) position to intrude
upon it's table structure. While this is perhaps not completely
germaine to EJB (I'm not so familiar with the details of the spec,) we
have found value in the 3-table approach in general O/R use.
If you make use of the 3-table method, the table that contains the
row-data is then only specific to the OBJECT that is stored in the
relationship. For instance, if I have:
COMPANY ----------- EMPLOYEE
1 *
in one application, and
CLIENT ------------ EMPLOYEE
1 *
in another application, we are not forced to deal with extraneous
columns relating the EMPLOYEE to either a COMPANY or a CLIENT (I
realize a better model might be to have company and client both
subclasses of EMPLOYER, or some such thing.) This example is
perhaps even better if we consider the use of EMPLOYEE alone without
it's COMPANY or CLIENT relationship.
Using the third table for the mapping keeps the individual component
entities well isolated, which can be a good thing.
Don't know if that was clear, but we've seen a use for the overhead of
the 3rd table.
Dumitru Sbenghe writes:
> SV: O/R mappingI care; If you store a 1-m relation in 3 tables, to get the
> corresponding data from the third table
> for a PK from the first table, you must join the second table with the third
> table;
> A join is slower than a simple select;
>
> If you store a 1-m relation in only two table (the normal way) , you do that
> with only a simple select.
... Someone else previously ...
> >
> > I'd like to point out that a third table is only needed for a N-M
> > (many-to-many) relationship.
> > In the case of a 1-N relationship, simply have a foreign key to the
> > master table.
--
Sean P. McNamara <[EMAIL PROTECTED]>
SOMA Technologies, Inc. <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
