What is a good inheritance strategy with Hibernate and JPA?

Question

I have this situation:

I have an entity, Person, that contains all personal details of a person, like birth date, street address, municipality ecc ecc. And I have an entity ClubMember that describe a member of a club and contains some field like: registration date, type of member, credit, ecc ecc

So, a ClubMember is a Person, and I think is correct describe this with a inheritance: ClubMember extends Person, but, what type of strategy?

I would obtain two table in database, Person and ClubMember, with ClubMember that contain id_person like an @OneToOne relationship, but keep the inheritance between entities; is this possible (and is correct)?

JOINED is the strategy closest to my target, but I lose the ID field of table ClubMember, in fact ID become the ID of table Person...

Solution 1

Blow, you should keep performance issues when choosing some kind of inheritance strategy. Here you can see a good insight about available inheritance strategies. Do not forget a inheritance can be re-writen as a association as follows

instead of

public class A {}

public class B extends A {}

you can use

public class B {

    private A a;

}

Or you can use MapedSuperClass To map all of your inherited properties whitout using any Hibernate/JPA inheritance strategy. See here

Keep in mind when using default JPA/Hibernate annotations, Hibernate always fetch all of subclasses. If you have a single hierarchy, prefer To use Single Table Inheritance strategy. Joined strategy is better designed when you have a complex hierarchy but it suffers due To performance issues when querying for any entity.

Solution 2

EDIT: below answer assumed NHibernate, apologies beforehand if it doesn't apply to Hibernate

This is not always trivial, even it can be trivially implemented (see below), and should be considered thoroughly. In my experience, it's best to stick to good old aggregation, or even just fields, where each ClubMember has-a person, instead of is-a person. This may not entirely feel right, but it works easier with your configurations, the CRUD operations and your abstract DAO classes. Auto-mapping tools often don't support subclassing out of the box.

Also, people that work with both your database and the DAL, will have an understanding for this mapping (i.e., Person as a one-to-one mapping to ClubMember, add non-null to the Person-property and you have your constraint as well), because it resembles the database more closely. You may argue of course that the whole idea of ORM is to remove this similarity ;).

If you want to experiment on this path or if you like to see how it's done and apply it to your situation, Ayende has a nice blog on the subject of NHibernate and inheritance. It's a bit basic, but you'll get the idea. If you use Fluent NHibernate, it becomes a bit easier even, see this brief tutorial.