• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Paul Clapham
  • Jeanne Boyarsky
  • Junilu Lacar
  • Henry Wong
  • Ron McLeod
  • Devaka Cooray
  • Tim Cooke
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Frits Walraven
  • Tim Holloway
  • Carey Brown
  • Piet Souris
  • salvin francis
  • fred rosenberger

Hiberate Table Design Quetions

Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
Posts: 10336
Hibernate Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 ]
Yan Hu
Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Paul.
I am mighty! And this is a mighty small ad:
Devious Experiments for a Truly Passive Greenhouse!
    Bookmark Topic Watch Topic
  • New Topic