I'm currently reading "Java Persistence with Hibernate" and the author encourages the reader on multiple occasions to not use many-to-many mappings and that entire enterprise applications can be written with only one-to-many / many-to-one mappings.

I'm curious .. what exactly is it with many-to-many that's so bad? Why should it be avoided? And how would you map a classic many-to-many usecase (a person can attend multiple events, an event can have multiple participants) with just one-to-many / many-to-one?

Actualy, I was also just condering why many-to-many should be avoided.

Could anyone explain?

tx,
Stijn

It's not something that standard SQL supports.

Consequences are:

1) Hibernate has to work harder to make it happen. Hibernate needs to execute more code (increasing the probability of hitting a bug), which is less well tested (again increasing the probability of hitting a bug).

2) If something goes wrong, you'll have more trouble finding the cause (because Hibernate is executing more and more intricate code).

3) More importantly, the Java data model is farther removed from the database model. This makes it harder to check that the models still match, both for you and for automatic validation.

4) Most importantly, experience suggests that most many-to-many associations get turned into two one-to-many associations anyway.
Say, you have persons and clubs and what to track who's a Member of what Club - that means a many-to-many relationship. However, more often than not you'll find that you want to track not just the fact that a person is a member of a club, but associated data as well - such as date of joining, membership fee, whether that fee is outstanding, etc. etc. So you need Membership objects, which will have one-to-many relationships with Member and Club. I.e. the link between Member and Club acquired attributes and had to be turned from "link" to "object", requiring you to restructure your code everywhere you access clubs from members or vice versa.
What follows is that a many-to-many association is ok if you can safely exclude that you'll ever want to associate attributes with a link, and use two one-to-many associations otherwise to make the data model a bit more stable (it will change far too much anyway).
(For one-to-many associations, if the link acquires an attribute, you can place the attribute in the object on the "many" side of things.)

Excellent explanation, tx a lot!

You're welcome :)

Actually I'm not sure whether I covered all aspects.
Many-to-many relationships are such a basic "you just don't do that" concept that it's actually hard to remember the exact reasons.
So: if anybody has practical experience with the trade-offs around many-to-many relationships, I'll be interested.