That's an interesting find Joe. That does sound like a better way to
go, to create the linking table object.
It also makes sense to me now that it bulk deletes, and adds them all
back in. I wonder if it takes advantage of inserting all the records
back in with one INSERT statement that SQL Server 2008 supports now.
On Jul 20, 12:50 pm, Joe Rinehart <
joe.rineh...@gmail.com> wrote:
> Found the Hibernate team's summary of it in best practices:
>
> Do not use exotic association mappings:
>
> Practical test cases for real many-to-many associations are rare. Most of
> the time you need additional information stored in the "link table". In this
> case, it is much better to use two one-to-many associations to an
> intermediate link class. In fact, most associations are one-to-many and
> many-to-one. For this reason, you should proceed cautiously when using any
> other association style.
> (
http://docs.jboss.org/hibernate/core/3.3/reference/en/html/best-pract...
> )
>
> On Wed, Jul 20, 2011 at 12:44 PM, Joe Rinehart <
joe.rineh...@gmail.com>wrote:
>
>
>
>
>
>
>
> > + 1 to "Nature of the Beast."
>
> > This is one of the reasons that ManyToMany is evil and should be avoided in
> > favor of a relationship class (AccountRole) and two OneToMany's (Account
> > OneToMany AccountRoleRelationship, and Role
> > OneToMany AccountRoleRelationship). The primary other reason is that the
> > relationship itself often becomes a model as new requirements are
> > discovered. For example, what if you needed to track the date an account
> > was added to a role? You'd be up the creek without an
> > AccountRoleRelationship CFC.
>
> > There's a much longer section on this somewhere in Java Persistence with
> > Hibernate, but it boils down to "Yeah, we support ManyToMany, but don't use
> > it, please."
>
> > -Joe
>