Hibernate: table per concrete class vs. table per subclass

Question

I'm planing / designing my database for my current project (Java). For this project I'm going to use hibernate.

In my project I have a base class/interface called Command. In fact the Command class contains only a field id (unique).

public interface Command {
   public int getId();
   public void execute();
}

So what every subclass of Command has in common is an unique id and a method called execute, which is implemented by the subclasses.

There exists many sub classes like MoveCommand, ResizeCommand etc. which has no common data fields (except the id).

For example:

public class MoveCommand implements Command {
   private int id;
   private int oldX;
   private int oldY;
   private int newX;
   private int newY;
   public void execute() { ... }
   public int getId(){return id; }
}

public class ResizeCommand implements Command {
   private int id;
   private int oldWidth;
   private int oldHeight;
   private int newWidth;
   private int newHeight;
   public int getId(){return id; }
   public void execute() { ... }
}

Then I have another class called Document, which contains a list of commands

public class Document {
  private List<Command> commands;
}

So a lot of queries of the base class "select from Command" were executed on runtime.

My question is: What kind of inheritance strategy should I use in this case to get the best performance.

In SQL: does JOIN (table per subclass ) or UNION (table per concrete class) perform better in this case?

Does anyone has experience with this topic?

I guess table per subclass would be the better (design) solution, but I'm not sure about it, since there would exist a database table with a single column (id), because that's the only thing that commands have in common.

Answer 1

I would expect the union strategy to be faster, because it needs less joins, but it really depends on what your application does. Since the base table doesn't contain any other column than the ID, it's not really useful anyway.

The differences between both aproaches are mainly related to normalization. The join strategy allows defining foreign keys to any class in the hierarchy (even the base class), whereas the union strategy only allows foreign keys to the concrete classes. This might be an issue for your join table between document and command. The union strategy also implies duplication of the common columns, but you don't have any in your case, so it's not really an issue.