48

I have a one-to-many relationship modeled using join table:

create table t1 (id int primary key, name varchar(10) /*...*/);
create table t2 (id int primary key, name varchar(10) /*...*/);
create table t1_t2 (t1_id int, t2_id int, primary key (t1, t2));

The tables are supposed to model the relationship of one t1 to many t2. What is the right way to model these tables using JPA?

Darrell Teague
  • 4,132
  • 1
  • 26
  • 38
Hosam Aly
  • 41,555
  • 36
  • 141
  • 182
  • 1
    I think you can find what you are looking for at https://en.wikibooks.org/wiki/Java_Persistence/OneToMany#Example_of_a_OneToMany_using_a_JoinTable_database – Legna Aug 16 '17 at 04:42

1 Answers1

77

The typical table for one T1 to many T2 is to have a foreign key on T2 pointing toward T1. The T1_T2 table is usually not needed.

The JPA structure would then be a One-To-Many, possibly two-way.


There could be some arrangements, to make the structure you describe work. You could change T1_T2:

  • add a unique constraint on T2 (so that only one T2 is allowed)

Is that really what you want?

Edited: yes, it is what you want ;-)

I doubt you may find many examples on the net. I have no proved solution, but I would try something along these lines:

In Hibernate annotation reference documentation, see "2.2.5.3.2.3. Unidirectional with join table" to get the idea. It looks like:

    @Entity
    public class Trainer {
        @OneToMany
        @JoinTable(
            name="TrainedMonkeys",
            joinColumns = @JoinColumn( name="trainer_id"),
            inverseJoinColumns = @JoinColumn( name="monkey_id")
        )
        public Set<Monkey> getTrainedMonkeys() {
        ...
    }
KLE
  • 23,689
  • 4
  • 56
  • 62
  • 2
    Thanks for your reply. It's true that mine is not the most typical structure, but I have other reasons that make it more suitable. The unique constraint on T2 is possible, but I still don't get how I should model it using JPA annotations. Could you please explain further? – Hosam Aly Sep 04 '09 at 12:02
  • OK. I'm curious of what could makes this design "more suitable" though. Could you give some hints, to improve my knowledge in case I need this in the future? – KLE Sep 04 '09 at 12:14
  • 10
    Thank you. That's really informative. As for the design, when the number of records in T2 which are actually related to T1 is relatively small, you may opt to having a separate join table rather than having a `t1_id` in T2 that is mostly `NULL`. – Hosam Aly Sep 04 '09 at 13:39
  • Excellent justification. Thanks for sharing ;-) I'll give you my vote ! – KLE Sep 04 '09 at 13:54
  • 9
    I have a case where keeping the join table is not just more suitable, but mandatory. When the child entity can be the 1:M child of multiple types of parent entities. In that case you cannot have the fk column in the child entity and must go with a join table. – Dave Jan 22 '13 at 18:47
  • 6
    HDave is correct - it is a very common pattern to have intermediary tables and not always a direct relationship. Consider Cars and Owners or any other example. A Car coming off the assembly line may have a VIN but not an Owner but if there is one there is only one. In such a case, there would be both Owner and Car tables plus an Owner_Car table that shows what Cars a given Owner has (which may be many). There is no direct FK from Car to Owner. JPA makes this painfully difficult (IMHO) perhaps due to an over-simplified set of cases it was originally designed to solve. – Darrell Teague Feb 05 '13 at 15:05
  • 2
    A real scenario could be a document class entity, where documents could be related in many other entities, and keep all relationships manage from the others. I hope this could be clarifier to others. – Miguel Cabrera Aug 28 '19 at 12:54