Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Inheritance at the database table level, Jpa Joined strategy

 
Julien Martin
Ranch Hand
Posts: 384
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have been working with a data model for quite a while. I now believe the model is flawed but I am not sure how to improve it.

Basically my domain model is a small ads website for parents seeking nannies/childminders and childminders seeking babies to look after.

The domain model currently has an base Account class that is subclassed by two ParentAccount and ChildminderAccount classes. I also have base Advertisement class that is subclassed by three ChildminderAdvertisement, ParentToParentAdvertisment and ParentToChildminderAdvertisement classes.

Most of the attributes are common to subclasses and therefore located in the super class.

To list a few differences between subclasses:
-A ChildminderAccount may have a Curriculum/Resume attached to it but a ParentAccount may not.
-A ChildminderAccount is further refined by specifiying whether the Childminder(generic) is a Nanny(specific)/BabySitter(specific)/etc.

This means that the ChildminderAccount subclass has relationships to other tables that the ParentAccount subclass does not have.

The inheritance is currently implemented by the JPA layer using the Joined strategy (see JPA documentation: )

I am facing a number of problems with the current design:
-I am having problems running operations common to base classes.
-I often find myself re-implementing methods for subclasses, I have too many DAOs.

As I said above, I am not sure how to improve the design: whether to forgo inheritance altogether (db level) or whether to go for another inheritance strategy...

Any clue welcome.
diagram.png
[Thumbnail for diagram.png]
diagram
 
James Sutherland
Ranch Hand
Posts: 553
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Since you state most of your data in common, you would probably be better off using SINGLE_TABLE inheritance instead of JOINED.

What specific problems are you having?
 
Julien Martin
Ranch Hand
Posts: 384
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
James Sutherland wrote:Since you state most of your data in common, you would probably be better off using SINGLE_TABLE inheritance instead of JOINED.

What specific problems are you having?


Hello James,

Here is a partial list of the problems I have:
-I find it difficult to factor operations on the subclasses, e.g. I want to be able to operate on all advertisements belonging to a given account (using a given account_ID); since the account_ID FK/JoinColumn is located in subclasses of Advertisement, I have to write as many methods as there are subclasses.
-A corollary of the above reason is that I have to maintain 4 Advertisement DAOs one for each class (one for Advertisement superclass and three for the Advertisement subclasses).

J.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic