5

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...

messivanio
  • 2,263
  • 18
  • 24
blow
  • 12,811
  • 24
  • 75
  • 112

3 Answers3

5

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.

Community
  • 1
  • 1
Arthur Ronald
  • 33,349
  • 20
  • 110
  • 136
  • Your last paragraph is interesting. It reminds me of *why* lazy loading was so important, why it can become icky with too smart hierarchies and why aggregation with a field is often a better option (reads easier, easier to maintain, easier lazy-load, regardless the depth of relations). Apparently that's true (logically so) for both Hibernate and NHibernate. – Abel Aug 01 '10 at 08:46
  • 1
    ok definitively i think to use an association instead inheritance. Thanks. – blow Aug 01 '10 at 09:23
1

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.

Abel
  • 56,041
  • 24
  • 146
  • 247
  • Sorry but i use pure Hibernate/JPA, not NHibernate... so your advice is to use @OneToOne relationship and not an inheritance, isn't true? I have no problems to implements it, but is a bit illogical :) – blow Aug 01 '10 at 00:05
  • @blow: that's indeed my advice. But, on looking at JPA, you may choose something else. Inheritance is rather trivial with the JOINED strategy you already suggested. But perhaps someone with more JPA/Hibernate knowledge can shed some more light on the issue. I'm sure you know this already: http://www.jpox.org/docs/1_2/jpa_orm/inheritance.html? – Abel Aug 01 '10 at 00:16
0

I would make ClubMemeber extend Person, as you suggested, and use the table per class heriarchy mapping strategy.

http://docs.jboss.org/hibernate/stable/core/reference/en/html/inheritance.html#inheritance-tableperclass

hvgotcodes
  • 118,147
  • 33
  • 203
  • 236
  • TABLEPERCLASS make one only table in database, i would obtain two separate tables, Person and ClubMember, i need Person in a single and clear table for re-use pourpose. – blow Aug 01 '10 at 02:14
  • @blow i don't understand why it makes a difference, but if you must have two tables, then use the table per concrete subclass approach, as you were going to. – hvgotcodes Aug 01 '10 at 02:17