开发者

How to implement n:m relation in Java?

开发者 https://www.devze.com 2023-01-20 11:50 出处:网络
I need to implement an n:m relation in Java. The use case is a catalog. a product can be in multiple categories

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

My current solution is to have a mapping class that has two 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 elegant solution where I don't need to index the data twice.

Plea开发者_运维技巧se en-light 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.


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.


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.


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.


If you're able to use an immutable data structure, Guava's ImmutableMultimap offers an inverse() method, which enables you to get a collection of keys by value.

0

精彩评论

暂无评论...
验证码 换一张
取 消