Win a copy of Murach's Python Programming this week in the Jython/Python forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Can anyone please explain Entity Inheritance and Polymorphism in simple words  RSS feed

 
Akshay Sahu
Greenhorn
Posts: 26
Java Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Its a humble request to the people who have the knowledge of Entity Bean Inheritance and Polymorphism, to please explain

Single table per class hierarchy
Separate table per subclass
Single table per concrete entity class


concepts in simple words. I have tried to learn it from three (3) different books, but was unable to understandit. Please do not ask me to refer any other book, as I am tired of doing so...!!! I am trying hard to understand those concepts since the last 2 weeks. I think you understood my frustration level.

Thanking You (In Advance),
Akshay Sahu
 
Hussein Baghdadi
clojure forum advocate
Bartender
Posts: 3479
Clojure Mac Objective C
 
Paul Sturrock
Bartender
Posts: 10336
Eclipse IDE Hibernate Java
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Single table per class hierarchy

This pattern means you have one table for all objects of a particular base type. So you might have a "shape" table which contains circle, square and triangle objects that all inherit from shape. In the data model they are differentiated by a differentiator column, for example a "type" column (perhaps a single character field with values 'c','s', or 't'). Personally, I would never recommend this pattern since it weakens the data model to make it easier to access it from one particular technology; you introduce lots of nullable fields and force non-JPA clients to understand the same logic. More of an anti-pattern as far as I'm concerned.


Separate table per subclass

Using the same classes as above this would have four tables, one for shape containing the common properties and one each for circle, square and triangle containing properties specific to those specializations. You would map this with joined subclasses. Again, this is a bit of an anti-pattern requiring joins for accessing otherwise simple entities.


Single table per concrete entity class

This is pretty much what it says, there is a one to one mapping between a class in your domain model and a table in your data model. So this time we would have three tables, one for circle, square and triangle. Any properties common to all shapes will be replicated on each table. This is far cleaner as far as the data model goes but does introduce a degree of data model awareness in your domain model, and (theoretically) redundant columns.

None of these patterns are perfect, but ORM is trying to bridge a gap that cannot be bridged perfectly. Its all about compromises.

Make any sense?

(BTW: "Entity Beans" are a specific historical EJB technology. Its worth making a distinction between "entities" - or mapped classes - as you are describing and Entity Beans)
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!