Home/ Questions/Q 6972575
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-27T16:59:14+00:00

Even though my question is worded specifically to the way Entity relationships are depicted

  • 0

Even though my question is worded specifically to the way Entity relationships are depicted in the Play framework, which uses Hibernate, I am sure this is a general concept.

When we have a one-to-many relationship, we are always asked to specify the owning side.

So, for example if we had a one-to-many relationship between Person and PhoneNumber, we would write code like this.

@Entity
class Person {
    @OneToMany(mappedBy="person")
    public Set<PhoneNumber> phoneNumbers;
}

@Entity
class PhoneNumber {
    @ManyToOne
    public Person person;
}

In the code above, the owning Entity is PhoneNumber. What are the pros and cons of either side being the owning entity ?

I realize when the owning entity is PhoneNUmber, the relationship represented is ManyToOne, which will not result in a join table, whereas when the owning side is Person, the relationship depicted would be OneToMany, in which case a relationship table will be created.

Is this the main reason for determining the owning side, or are there other reasons as well ?

Update:
I just realized that this thread provides part of the answer, but I am hoping there may be other points as well.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    With most ORM layers you have concept of lazy loading. When you create a Person object it will not load phones set unless asked to. At times how you want to lookup data can also dictate how you store it.

    Like if you want to bring up person first and then show phone numbers on demand then keeping person references in phone is fine. First you fire a simple query to load person data and then just lookup phone numbers based on an (already loaded) person.id (another simple query)

    Whereas for showing person + phone data at one go, you would prefer having a join table where you can just load data based on person table + person-phone join table using person id as keys into phone table, all in one go. Here it would be expensive to do lookups without a relationship table.

    But quite frankly, if you think SQL instead of ORM then you would go with a relationship table every time 😀

    • 0