• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Jeanne Boyarsky
  • Tim Cooke
Sheriffs:
  • Liutauras Vilda
  • paul wheaton
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Carey Brown
  • Frits Walraven
Bartenders:
  • Piet Souris
  • Himai Minh

Inheritance at the database table level, Jpa Joined strategy

 
Ranch Hand
Posts: 384
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
Ranch Hand
Posts: 553
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
We begin by testing your absorbancy by exposing you to this tiny ad:
Free, earth friendly heat - from the CodeRanch trailboss
https://www.kickstarter.com/projects/paulwheaton/free-heat
reply
    Bookmark Topic Watch Topic
  • New Topic