Hi,

The Hibernate Reference (Section 7.2.3) mentions that :

Could any one please shed some light on why exactly it is not recommended? Why is it that the counter-argument, viz. that by skipping an intermediate association table we are avoiding an unnecessary join (and table), doesn't hold good?

Thx,
Vikas

For one thing, it doesn't make much sense conceptually. The association is driven by the foreign key on your child entity, so that is really the managing side of the association. The simplest form is to have the parent unaware of the children, and each child simply aware of its parent through a many-to-one. Then when you need children, you query for them.

If you want to map the collection on the parent entity, you can add the <set> or whatever, and mark it inverse=true because the children still own/manage the association through the foreign key.

When you do a unidirectional one-to-many, the parent becomes the managing side of the association and this doesn't match up well with RDBMS relationships. You get things like extra updates -- when you insert a parent + children, you'll get inserts on each, then subsequent updates setting the parent ID on each child. It's just ugly.

So they say if you need a mapped collection towards children that are unaware of their parents, you use an association table because it makes more sense relationally and works a whole lot better.

But in your case, just use a bidirectional relationship :)

I should add that if you need a true parent/child relationship, the best way to get this is by using a collection of components, not an association mapping.

http://www.hibernate.org/hib_docs/v3/re ... ollections

This makes the children bounded by the lifecycle of the parent and works like you might expect. You cannot query for the children on their own, however.