How do you model/map a heavily reused child class/table to many different parent entities?

I have several entity types each being persisted into its own table:

class A --> table A
class B --> table B
....

Now I need to make each of these classes the parent of a 1:M child collection. The collection is a history of approvals the entity has gained over time. The Child domain class is called "ApprovalItem". The Approval class is exactly the same for all types of parents.

What is the best way to map this? If I create a single table to hold all ApprovalItems, then I can't enforce a FK relation to the PK of the entity and I am left with a bad database design.

On the other hand, I could create an ApprovalIems for each entity type (e.g. A_ApprovalItems, B_ApprovalItems, etc.). This seems like a good schema on the database side, but then it seems I need to create a separate domain classes in Java for each entity approval (e.g. AAprrovalItem class, BApprovalItem class, etc.). This seems like a lot of hassle and complexity to create so many new classes in Java that do nothing other than allow me to put in different JPA mapping annotations.

Is there a mapping technique in Hibernate that will allow me to have one class in Java map to several different tables depending on who the parent owner of the collection is?

We have a somewhat similar situation in a project I am involved in. We have solved it by using an extra step in-between. In your terms it would be an 'ApprovalSet'. Eg. class A (and class B, etc.) has a many-to-one to ApprovalSet which has a one-to-many to ApprovalItem.

So, in table A, table B, etc. there will be an extra column 'approvalset_id', that is a foreign key to a new table: ApprovalSets. This table doesn't need anything more than the id, but we are also storing the class of the owner so that we can go in the other direction. Then the ApprovalItems table also needs an 'approvalset_id' column so that we know which set it belongs to.

If you wrap this up in some utility methods and with proper cascade options you will almost never have to work with the ApprovalSet items. This works fairly well for us. The main drawback is that it is uni-directional and it is not possible to do queries on ApprovalItems and join the path up to the owner. There is also a risk that two or more parent items all point to the same ApprovalSet, but this can be solved in the utility methods.

Thanks for your response. That's a good idea. In the meantime I also heard another idea which is to create join tables such as (A_ApprovalItem) and use them also like your ApprovalSet except that it is not it's own entity. In my case I think this could work without having to create another Java class. Make sense?

I guess that would work too. You will get a lot of tables though...

The approach would not be convenient in our case. We have mapped the association to the (equivalent of) ApprovalSet on a superclass so we get the connection simple by subclassing this class. No need for extra mapping of join tables for each subclass.