how to implement n:m relation in java?

Question

Sorry for this newbie question, but I just never worked with java... My problem is I need to implement an n:m relation in java. The use case is a catalog.

• a product can be in multiple categories
• a category can hold multiple products

the classic...

My current solution is to have a mapping class that has to hashmaps.

• The key of the first hashmap is the product id and the value is a list of category ids
• The key to the second hashmap is the category id and the value is a list of product ids

This is totally redundant an I need a setting class that always takes care that the data is stored/deleted in both hashmaps.

But this is the only way I found to make the following performant in O(1):

• what products holds a category?
• what categories is a product in?

I want to avoid full array scans or something like that in every way!

But there must be another, more ellegant solution where i don't need to index the data twice! Please enlight me... I have only plain java, no database or sqlite or something available... I also don't really want to implement a btree structure if possible.

Answer 1

Your solution is perfectly good. Remember that putting an object into a HashMap doesn't make a copy of the Object, it just stores a reference to it, so the cost in time and memory is quite small.

Answer 2

If you associate Categories with Products via a member collection, and vica versa, then you can accomplish the same thing:

public class Product {
     private Set<Category> categories = new HashSet<Category>();
     //implement hashCode and equals, potentially by id for extra performance
}

public class Category {
     private Set<Product> contents = new HashSet<Product>();
     //implement hashCode and equals, potentially by id for extra performance
}

The only difficult part is populating such a structure, where some intermediate maps might be needed.

But the approach of using auxiliary hashmaps/trees for indexing is not a bad one. After all, most indices placed on databases for example are auxiliary data structures: they coexist with the table of rows; the rows aren't necessarily organized in the structure of the index itself.

Using an external structure like this empowers you to keep optimizations and data separate from each other; that's not a bad thing. Especially if tomorrow you want to add O(1) look-ups for Products given a Vendor, e.g.

Edit: By the way, it looks like what you want is an implementation of a Multimap optimized to do reverse lookups in O(1) as well. I don't think Guava has something to do that, but you could implement the Multimap interface so at least you don't have to deal with maintaining the HashMaps separately. Actually it's more like a BiMap that is also a Multimap which is contradictory given their definitions. I agree with MStodd that you probably want to roll your own layer of abstraction to encapsulate the two maps.

Answer 3

I would go with your first solution. Have a layer of abstraction around two hashmaps. If you're worried about concurrency, implement appropriate locking for CRUD.