We're starting up a new project, and trying to decide which way we should model our tables and handle inheritance, per-heirarchy, or per-subclass. It seems like each one has a major drawback that we don't like, and I wanted to post and see if there are recommended ways around these drawbacks.

Per-Hierarchy - You have to make all the columns from the child classes nullable, since you can't have the DB inforce it for one class type insert, but not another.

Per-Subclass - If you have a User and a Teacher, which both inherit from Person, you need to have duplicate Person information in the DB when you create a User and a Teacher, since the ID that the child classes get is really the Person's ID.

Am I understanding both of these cases right? Are they good ways around them that my newbie eyes don't see?

Thanks.

option 1- discriminator option (one field determines subtype)- I agree, that the not null fields are an issue, but this is not hibernates fault really- i think it's not such a good relational model to begin with (not very normalized)

Table per hierarchy means there is no table for the superclass(person), just tables for the subclasses. I think this is workable. I've used this with success before.

Table per class, and subclasses- seems like the way to go, although I'm a little confused myself on the docs when it seems to say this mapping can't be used in a collection (from one-many)

when you say "you have to have duplicate infoin person, and user"- may be incorrect
the only duplication you would have would be the PK...

good luck with your decision


James

In the java code though, how would I create a new Teacher and have it use the Person info that's already in there? Isn't it going to try to insert another Person?

Thanks.

This is more a OO question.

As User and Teacher are really separate entities, no where data is getting duplicated.

When you see from User and/or Teacher perspective, it is actually the subclass's ID and not the Person's ID. Because when you save or load User/Teacher, you're saving/loading the whole object and dta will be saved in Person related table also because these subclass entities are of type Person.
[/quote]

But what about when you have a user of the system who is a User and a Teacher?

This is a simplified example, so in this case, there were only be a few columns of duplicate data, but in the real examples we're looking at here, this would happen quite often.

Well, thats just an OO modelling question - model it using aggregation rather than inheritance would be a good idea I think.

But if a User "is a" Person and a Teacher "is a" person, then wouldn't we want to model the objects that way?

Yes? And how would you model it? Then I can tell you how you can map it probably.

To me, if a User "is a" Person, and a Teacher "is a" Person, then I would make User and Teacher inherit from Person. That way you can treat them both as a Person when doing "person stuff".

Yes, but if you model it this way, an object can be either a Teacher or a Person ...

I must be missing something...you say that like it's a bad thing.

Well you asked about data being duplicated in the DB - of course it is going to be duplicated if you have two objects for the same person. Hibernate just creates a relational representation of your object model.

If I was writing my own SQL for this, a Teacher would have it's own id, and a foreign-key personId on it, and then on insert, if the personId is already set, then I would assume that this is an existing Person, and just insert the new Teacher.

But there are 2 problems with that way and Hibernate.

1) Hibernate doesn't have that logic (nor do other O/R mapping tools that I've seen)
2) With Hibernate, my Teacher's ID is really the ID from the Person table.

That's really the method that we'd like to do, but I don't know if we'll be able to do that using an OR mapping tool.

This is an OO question, really.

The main question is: is a Teacher ALWAYS a User, and is a User ALWAYS a Person? If so, then use inheritance Person -> User -> Teacher. If a Teacher can sometimes be a User and sometimes not, use delegation. (A Teacher can contain a User object which contains all info used to access the system.)

Maybe if you thought of the User object more as a UserProfile object, that would help. (UserProfile being only the information used to access the system, not the identity of the user. (little "u" intended)) Then you have Person -> Teacher with a Person or Teacher containing a UserProfile object.

I don't really think this is an OO question. You're the 3rd person to say that. A Teacher is a Person, and a User is a Person. Sometimes, in real life, they could be the same person (lower case p), and I would want to reuse the Person (upper case P) when that happens. I don't think it's an OO question, because, to me, it's pretty clear that Teacher should inherit from Person, and User should inherit from Person. I'm just modeling the objects like they are in real life.

I don't want to use aggregation, because I don't want to lose the ability to treat Teachers and Users as a generic Person. Also, it seems forced here, when the natural way to do is to use inheritance. I don't want to have to force my object model into something, just to fit the OR Mapping tool.