We are developing the Web App that will have user subscription to a specific group of events.
For example: User create a comment in the blob and all users subscribed to this blog should have this event in their list.
Currenly, we are searching for the data model to store this data.
Store all events in one table seems a good idea from the usability point of view:
- Object (in the example: comment reference)
- Subscribable object(in the example: blog reference)
- User that spawned the event
- Event type(like: update, create etc.)
The subscription events for particular user may be gathered by the sql query that will filter events by user subscription.
The problem in this data model is that subscribable objects may may have ‘inheritance’. For example: The user might have a subscription to the blog or to particular posts in the blog.
That means that Blog subscription extends post subscription and this data model doesn’t reflect this behavior. I will have to spawn 2 events in this case: one for blog and one for post.
Is it a good idea to have all events around in one table or split them some how into different tables? Anyway event tables will have a huge amount of data. Is there a better idea to organize event logging?
Subclasses in one table and subclasses in separate tables is a common question.
There is no “good idea” answer. Both are good ideas.
One question is how you will query them.
If you rarely do a union of all distinct event subtypes, and you have little overlapping functionality, then separate tables may work out well.
If you often do a union-style query that pulls together several distinct event subtypes, or you have a lot of overlapping functionality, then a single table may work out well.
Another question is one of polymorphism.
If all your event subtypes are properly polymorphic, then your application (and database) will be working with mixed collections of event subtypes. This leads you to a single table.
If your event subtypes are all very different, and cannot be used polymorphically, then they should be in separate tables.
Consequences
With all subtypes in one table, you must use NULLABLE columns for those attributes that are not common to all subtypes. You should also have a column which tells which subtype the row represents.
When putting multiple subtypes in a single table, you must have a discriminator column which tells which subtype the row should be.
When putting subtypes in separate tables, you have two designs.
Repeat common elements in all tables. Do this when there is very little in common.
Have subtype tables join to the supertype table, and put common elements in one table. Do this when almost everything is common.