Java tips for coders, by coders

Over the last couple of years I have had various discussions about this with my colleagues. I myself favoured foreign keys relationships rather than join tables till a little while ago. If you’re not aware of how to do one or the other, the eamples below should explain that.

Consider a very simple parent child relationship. Every parent can have multiple children. Using a join table and JPA annotations, the model classes look something like this for unidirectional relationships: (I have excluded all fields not required for this example)
With join table …

@Entity
class Parent {
    @OneToMany
    @JoinTable(
            name="parents_children",
            joinColumns = @JoinColumn( name="parent_id"),
            inverseJoinColumns = @JoinColumn( name="child_id")
    )
    private Set<Child> children
}

@Entity
class Child {
    //nothing
}

Without join table …

@Entity
class Parent {
    @OneToMany(cascade=CascadeType.ALL, fetch=FetchType.EAGER)
    @JoinColumn(name="parent_id")
    private Set<Child> children;
}

@Entity
class Child {
    // nothing
}

Why should you use a join table? For one, having the ID of the parent in the child makes no real sense because the child is a part of a parent, not the other way around so why place the parent information in the child table. Plus, if child entities can exist without parent entities then a join table is the only way to go unless you set the parent field to nullable which event further pollutes your data model. This is ofcourse from a completely domain model perspective, nothing is stopping you from doing it.

Another reason is that this model doesn’t scale very well when it comes to having different types of parents. Assuming that child can be part of two parent, we will then need to keep two seperate parent id’s in the child table. As long as you’re aware of how many parents a child has, it works but what if a child can have 1 … n parent, how do you then design your table? The join table approach scales very well.

Yet another reason, and this is more of a personal opinion than a concrete opinion, is that denormalizing data always helps. Ofcourse too much denormalization isn’t good either but this isn’t going overboard. My simple reasoning is that it is easier for the database to query a two column long only join table that a n field big table for a particular column. Performance gain or not, it’s always to have a very clean and easily seperatable data model than one with clumsy mixes all over the place.

So what approach do you use?

No related posts.