Hibernate suitable inheritance strategy

Question

This is the parent class

@MappedSuperclass
@Inheritance(strategy=InheritanceType.SINGLE_TABLE)
public  class APostCommon extends Actionable {    

   private static final long serialVersionUID = 1L;

   @Column(name = "TITLE")
   private String title;

   @Lob
   @Column(name="DESCRIPTION")
   private String description;

   //omitted others for purity
}

This is a child class

 @Entity
 @Table(name="QUESTION")
 public class Question extends APostCommon {

    private static final long serialVersionUID = 1L;

    @Transient
    private List<Answer> answers;

    @Column(name="FOLLOW_COUNT")
    private Integer followerCount;

    @Column(name="ANSWER_COUNT")
    private Integer answerCount;

    //omitted others for purity
}

Answer only differs from the superclass by including the questionId field

@Entity
@Table(name="ANSWER")
public class Answer extends APostCommon{

   private String questionId;
   //omitted others for purity
}

Which data model is suitable for me. Should I use InheritanceType.SINGLE_TABLE or TABLE_PER_CLASS. Whats happen when there is millions record in future.

Answer 1

As i was preparing for JPA Certificate, these are my cherry picked notes on both strategies:

Single Table Strategy

The approach may be more wasteful of database tablespace, but it does offer peak performance for both polymorphic queries and write operations.

The SQL that is needed to issue these operations is simple, optimized and does not require joining

• Pros in your case: Maybe your design will not be nice and normalized but you will spare yourself a lot of headache regarding performance, and also your queries will be a lot simpler especially if you are expecting to have millions of records for Questions and Answers.
• Cons in your case: I am guessing that Question and Answer will have a lot in common, but also, as the time goes and the table grows, a lot of distinct properties / columns. You might end up with one of those bloated tables that hold every possible peace of data and is unmaintainable at some point (not once i had to had approval of an entire department and days of testing to add a single index to one of the columns to a table like that).

Joined Strategy

Mapping a table per entity provides the data reuse that a normalized data schema offers and is the most efficient way to store data, that is shared by multiple subclasses in the hierarchy.

• Pros in your case: with time, the number of additional distinct columns between Question and Answer tables is not a problem as your schema is nice and normalized, therefore each of those has a logical place. The design is clean, clear, maintainable and scalable (possibly you might need to add more abstraction to specialized Questions and Answers).
• Cons in your case: with millions of rows for questions and answers, you will need at least one additional join for basic queries, though if you keep it normalized as the columns / features grows, the minimal number of joins will be higher than that.

Conclusion:

Initially i was leaning towards the Single Table, but as i give myself a bit of time, it made realize that would be a 'lazy' decision (put everything in one bag and forget about design).Joined Tables seems more of a mature decision as you need to think about your indexing strategy, into how many tables you should normalize (and which groups of data) and finally coming up with efficient queries, batch statements.

Decision is up to you, but if you go for the joined strategy you will definately increase your skillset as it will be more demanding.