How to decide which should be Parent table and which should be Child table while defining Parent Child relationship

Question

How do we decide which table should be a Parent Table and which table should be a Child table while defining Parent Child relation.

Say for example i am creating an one to one relation in hibernate. Now how can i decide which table should be parent and which should be child.

Do we have any thumb rules or any guidelines.

Also while defining one to one mapping in hibernate in which table should i define the relation. For example we specify the following tag to define the relation <one-to-one></one-one>. Should it be in parent table or child table if the relation is unidirectional.

I have also gone through the following links

Which table should be Parent table and which should be child table?

Which Table Should be Master and Child in Database Design

Please Suggest.

Is it that the table that holds the primary key has to be considered as Parent table ?

Rohit Gaikwad · Answer 1 · 2016-09-29T12:51:58.970

1) We should not care about the tables(Parent/Child) in hibernate. What you should do is implement your software design in Java(object oriented approach) and hibernate will do its job as per your software/project design.
The design of your project should not have any implementation dependency on any API like hibernate.

For example: lets say in your design you have a scenario where you want to implement an is-a relationship(inheritance) like "there are two kinds of employees in a company as regular and contract employee."
This scenario can be implemented in java as below:

class Employee {  
 private int id;  //applicable for both types of employees
 private String name; //applicable for both types of employees

 //getters and setters  
}  
class Contract_Employee extends Employee{  
    private float pay_per_hour;  
    private String contract_duration;  

//getters and setters  
}  
class Regular_Employee extends Employee{  
    private float salary;  
    private int bonus;  

 //getters and setters  
}

Its mapping with hibernate can be done as below:

<hibernate-mapping>
<class name="com.stack.Employee" table="emp" discriminator-value="emp">
    <id name="id">
        <generator class="increment"></generator>
    </id>
    <discriminator column="type" type="string"></discriminator>
    <property name="name"></property>
    <subclass name="com.stack.Regular_Employee" discriminator-value="regular_emp">
        <property name="salary"></property>
        <property name="bonus"></property>
    </subclass>
    <subclass name="com.stack.Contract_Employee" discriminator-value="contract_emp">
        <property name="pay_per_hour"></property>
        <property name="contract_duration"></property>
    </subclass>
</class>
</hibernate-mapping>

As Hibernate is ORM framework, it supports this kind of relationship and it has to. There are lots of evolvement ongoing in hibernate framework currently 5.x is the recent one. So as to solve many real world problems.

2) Remember, all the relationships(@OneToMany, @OneToOne, @ManyToMany, @ManyToOne etc.) are object oriented approaches to solve a particular real world problem.
So once you create the java classes for implementing these relationships & you want to store the objects as it is in the DB using ORM, you just need to keep the relationship as it is and do their corresponding mappings as per the ORM framework.
You should not change or decide what will be the parent/child table while implementing hibernate. This is decided right before implementing your java class.

3) Hence, the thumb rule is rely on your project design/requirement and not on its implementation in hibernate.
One should change/(add new) the back-end api in order to implement the design. This is because, a good software design does not depend on its underlying implementation.

4) The Database design should be done based on how the USE-CASE's are designed. In Use-Case diagrams all your relationships between the entities are defined for a scenario.

Suggestion: Just make good use of ORM frameworks, so as to implement your requirements.
Let designers do their job and developers implement the design as the designer wants to.

How to decide which should be Parent table and which should be Child table while defining Parent Child relationship

1 Answers1