Question

I have 2 entities, let’s say Client and Company (both subclass of User).
Each having a list of Events: ClientEvents and CompanyEvents

The reason we’ve split up those tables at first (instead of going with Events table) was that events of each kind don’t mix (you can operate only on one kind of event at a time). That would also result in having 2 smaller tables instead of one big table.

1. Is that a good way to go? (big table data volume ~1M)
   Maybe there is no need to split those tables in two and just use inheritance?
2. What would be the best way to model it as Entities?

The attributes and operations on both types of entities are identical so I could model it as:

 @MappedSuperclass  
 public abstract class **Event** {...}  
 @Entity @Table(name="client_event")  
 public class **ClientEvent** {...}  
 @Entity @Table(name="company_event")  
 public class **CompanyEvent** {...}

Now is there a way to query each type of specific event without duplicating methods in DAO (using hibernate or JPA, maybe generics would be of use here)?
3. Is there a ‘rule of thumb’ in situations like this (two separate beings but identical attributes and operations) to model database tables and entities?

Answer 1

It depends on the size of table (number of events in total), for how long you want to keep those events in an active table, frequency of new events and retrieval of old events.

You can keep one table if new events aren’t frequent. Its better to have two separate tables if the new events are very frequent and you need to search them often.

you can make the searching/retrieval faster by archiving those old events into one table.

In short, any design depends on the need of the business.

Multiple tables will allow you to search faster while single table will give you ease of access and simplicity of the code/design.

For the access, you can use same method, just pass the event type as the parameter and build the query upon that.