Do i always need to create separate class for manytomany relation in hibernate

Question

I was reading this article

http://www.mkyong.com/hibernate/hibernate-many-to-many-relationship-example/

But he created three classes

Stock
Category
stock_category

Do i always need separate table for relation or this can be done in 2 tables as well like only in Stock , Category

Answer 1

You have many-to-many relationship, you will need a junction database table, in your case Stock_Category table. That said, that junction table may not need to show up in as a Hibernate entity, depending on what you are trying to accomplish.

If your junction table merely holds the primary keys from Stock table and Category table, then you can use @ManyToMany. In this case, the Stock entity will have stock.getCategories() that returns all categories, while Category entity will have category.getStocks() that returns all stocks. The junction table doesn't appear at all.

However, if you are going to have additional behavior(s) into Stock_Category table, for example, if you want to capture who assigns the stock to the category or when it is added, then you will need to use @OneToMany and @ManyToOne instead of @ManyToMany. In this case, the junction table will appear as a Hibernate entity. So, the Stock entity will have stock.getStockCategories() that returns all the stock categories, while Category entity may also have stock.getStockCategories() (if you configure bi-directional relationship) that returns the same thing. The StockCategory entity contains additional properties, such as personWhoAddsTheStockIntoCategory or dateAdded, etc...

Hope this helps.

Answer 2

No. Never. This is common question that I have heard from many people. And the answer is that when you design entities :

You MUST not think in terms of Relations (RDBMS) but you must think in terms of Objects (Java).

In more details. Hibernate attempts to achieve a quite difficult task : connect Object Oriented Universe of Java with Relational World. It achieves it in most of the cases on a price of confusion between two paradigms.

The best strategy (and less painful) is to design your entities and let Hibernate to create schema for you. So assuming that

Stock entity refers to many categories (Set of Categories)
and
Category entity has a set of Stock ids

We have a many-to-many relationship navigable from both entities. And you need only two classes here.

Then you need to annotate (here I assume you are using annotations not .hbm.xml) these sets as many-to-many attributes (read the Hibernate Annotation Manual).

Compile the code. Then Configure Hibernate for automatic schema generation (hbm2ddl.auto is the property that enable schema generation). If everything is ok you will see 3 tables in the database 2 tables for entities and 1 table for many-to-many association (this is the 3rd Normal Form of schema, eg the cleanest one).

Then persist some entities and enjoy. And never forget Think in OO terms while using hibernate (there is no JOIN operation).

Answer 3

You need a separate table for the join in a man-many relation. You do not however need a separate Java class representing this join table.

In the cited article's code, Stock and Category both have Set<StockCategory> fields mapped with a @OneToMany annotation. You could instead use @ManyToMany annotations and entirely avoid the StackCategory class. The table would still have to exist and would be referenced in a @JoinTable annotation on one end of the relation.

See the docs on mapping associations for more details on how to do this.

Answer 4

You can't, in general, have two tables which have foreign key constraints on each other. Moreover, you would end up with multiple almost-duplicate rows in each table, which would complicate using them in ways not involving the many-to-many relationship.