Hiberate Table Design Quetions

Hello Guys
I would like to have your input on this design. I am using Hibernate.
Business requirements:
I have a table called Action which contains a bunch of actions to be executed at different times. Each row represents an action entity that is modeled using Action.java. The action object can be modified and then updated. For each action updated, I want to keep a copy of the old action. That is I would like to keep a history of that action.

The first approach is too have a ActionHistory Table and a different Class , namely ActionHistory.java

In the Action Table, there are only the root Actions. It is a one-to- many relationship between these 2 tables

In the java semantic, it looks like

Class Action {
// Other simple property
Set<ActionHistory> history = new Hashset();

}

Class ActionHistory {
// Other simple property
Action rootAction;

}

If I need to go back to any historic copy for an Acton, I only update the contents of that root action with that particular historic object in my history set.

Now here is another approach using hibernate.

Using only one table, namely Action, and one class Action.java. All history is stored in the same table with a flag showing which one is the most current.

I have problems being convinced it is a better solution than the first approach.

My major gripes with this second approach are

1. What semantic does this table have? Is it an Action Table or is it an ActionHistory Table? The semantic of this table would be very confusing.

2. Losing all benefits of using Hibernate such tracing relationship between objects. In order to load a history of an Action, I would write a HQL with the second apporach. With the first approach, I would only need to load the root Action, not to mention other benefits like automatic cascading operations In other words, it is more sql oriented. When we resort to Hibernate, aren�t we trying to minimize sql statements where we can?

What do you people think? Your input is greatly appreciated.

The first approach is the more common solution in relational databases (irrespective of whether Hibernate is involved or not). I don't see what the second solution gives you really, other than a more confusing ER model.
[ July 12, 2006: Message edited by: Paul Sturrock ]

Thanks Paul.