Usage of inheritance in Hibernate

[chets patel]

I would like to know How inheritance will be used in real world project.
E.g. Consider an example of Bank Account
Approach 1:

Account {
	String name;
	double balance;
	operation1() {
	}
}
SavingAccount extends Account {
	// some extra fields and methods related to saving account 
	operation1() {
	}
	
}

CurrentAccount extends Account {
	// Some extra fields and methods related to current account.
	operation1() {
	}
}

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:

Account {
	string name;
	double balance;
	string type;
	operation1() {
	}
}

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.

if (type == saving) {
	// do this;
} else if (type == current) {
	// do that;
}

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]

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]

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.