Granny's Programming Pearls
"inside of every large program is a small program struggling to get out"
JavaRanch.com/granny.jsp
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Many to Many implementaiton

 
Ayman Haboubi
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
I'm having trouble finding an exmaple of a many to many relationship implemented in java and using collections.

Is there a webiste or a link to an example that can help me with this.

Regards.
 
Peer Reynders
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A Customer object collects the references to all the Vendor objects that it uses in an internal Java collection.
The Vendor object collects the references to all the Customer objects that have purchased goods in its own internal collection.

Voil� - a many-to-many relationship.

Associative entities are used in data-models because you usually don't store collections inside a single record.

However once the Associative entities exist they often acquire additional properties (like the date of the first purchase, how many times the customer has purchased for the vendor, etc).
Now it may become necessary to create an intermediary object that carries these properties. In that case the Customer may contain an internal collection of references to CustomerVendorLink objects - the CustomerVendorLink object would contain the reference to the vendor object. The CustomerVendorLink object could also be used by the Vendor object, provided that the CustomerVendorLink object also has a reference back to the customer.

However the Vendor object may have an entirely different way of dealing with a customer so it may actually use its own VendorCustomerLink object which then contains a reference to the Customer.

So ultimately there is an (implied) many-to-many relationship between the Customer and the Vendor objects even though even though this relationship is facilitated over the CustomerVendorLink and VendorCustomerLink objects.

CustomerVendorLink and VendorCustomerLink are really bad names for the classes mentioned here - they should really reflect what the classes are all about. So in a ratings systems the Customer could refer to a number of its own VendorRatingInfo objects (each of which refers to a single Vendor object � i.e. a single customer is rating a single vendor) and the Vendor would refer to a number of its own CustomerRatingInfo objects (each of which refers to a single Customer object � i.e. a single vendor is rating a single customer).
[ October 26, 2006: Message edited by: Peer Reynders ]
 
Frank Carver
Sheriff
Posts: 6920
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A Customer object collects the references to all the Vendor objects that it uses in an internal Java collection.
The Vendor object collects the references to all the Customer objects that have purchased goods in its own internal collection.


Bear in mind, though, that a simple implementation of this can fall into a mutual dependency trap and cause strange compilation problems.

I usually recommend programming to interfaces in this case, but even that needs care. If you follow the "tell, don't ask" principle, you should be alright though. Here's an example of what I mean:

 
Peer Reynders
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Frank Carver:
Bear in mind, though, that a simple implementation of this can fall into a mutual dependency trap and cause strange compilation problems.


Good Point! Got to watch out for those nefarious cyclical dependencies.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Peer Reynders:
A Customer object collects the references to all the Vendor objects that it uses in an internal Java collection.
The Vendor object collects the references to all the Customer objects that have purchased goods in its own internal collection.


That's one way to implement a *bidirectional* many-to-many relationship.

If you remove one of those collections, you can still have a many-to-many relationship. Whether it's many-to-many or one-to-many simply depends on what you put into those collections (whether you allow one entity to be put into several collections at the same time).
 
Ayman Haboubi
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Wow Frank!!! that example is just what I wanted. I will study it well and try to understand it better.

Many a Thank you Peer for the extensive details and Ilja for your insight
[ October 28, 2006: Message edited by: Ayman Haboubi ]
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic