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

Usage of inheritance in Hibernate

 
chets patel
Ranch Hand
Posts: 77
Eclipse IDE Redhat Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I would like to know How inheritance will be used in real world project.
E.g. Consider an example of Bank Account
Approach 1:

When I map these classes with database, using Hibernate using one of the inheritance strategy, e.g. table per sub class, I will end up with three tables. Account, Saving_account and Current_account.
Advantage: I can call operation1() depending on the type of object using polymorphism.
Disadvantage: more tables and classes.

Approach 2:

I need only 1 table for this approach called Account. And "type" field will identify the type of the account.

Advantage: Only 1 table and class.
Disadvantage: I will lose Object oriented world and every place I have to put the condition as below.


As per theory, approach 1 is correct and best. But currently in my project, approach 2 is used. My project is not banking. I took it as an example for the simplicity. Also approach 1 is good for maintaining large complex projects.

Thanks in advance for your inputs.
 
Joe Ess
Bartender
Posts: 9340
10
Linux Mac OS X Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There's several ways to map inheritance in Hibernate: this article talks about the alternatives and their pros/cons.
I usually go with the first option (table per subclass). One can push shared fields up into the superclass/supertable so it goes well with database normalization. Since the database diagram closely resembles the class hierarchy it makes figuring out things easier.
The other options have their place, it really depends on one's requirements. For example, in one application we have a store of "notes" (call log, system generated events, user comments, etc.). Since the different "types" shared most of their fields (time, message, user or system that made the note, etc.) it didn't make sense to create a "class hierarchy" in the database but it did make sense to have different classes for the business layer. For this situation, we used the second option (one table per class hierarchy). This gives us a great deal of flexibility with the code without "cluttering up" our database with a half-dozen barely distinguishable tables.

Disadvantage: I will lose Object oriented world and every place I have to put the condition as below.


Yes, that is a Bad Idea. Polymorphism simplifies code and makes maintenance easier. Working around it just makes life more difficult.
 
Salil Vverma
Ranch Hand
Posts: 257
Hibernate Oracle Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Disadvantage: I will lose Object oriented world and every place I have to put the condition as below.


If you use table per class hierarchy, the class structure would have three classes ie Account, SavingAccount CurrentAccount. Most of the persistence related operations would be performed from the object/class of SavingAccount & CurrentAccount. In this way the object oriented nature of your java program would not get impacted.

If most of the attributes are same, we should prefer using table per class hierarchy & if many attributes are different table per subclass or table per concrete class could be used.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic