Web 应用程序中的用户事件订阅
我们正在开发 Web 应用程序，让用户订阅一组特定的事件。 例如：用户在 blob 中创建评论，并且订阅此博客的所有用户都应在其列表中包含此事件。
目前，我们正在寻找存储这些数据的数据模型。
从可用性的角度来看，将所有事件存储在一个表中似乎是个好主意：
- 对象（在示例中：评论引用）
- 可订阅对象（在示例中：博客引用）
- 产生事件的用户
- 事件类型（例如：更新、创建等） .)
特定用户的订阅事件可以通过 SQL 查询来收集，该查询将按用户订阅过滤事件。
该数据模型中的问题是可订阅对象可能具有“继承性”。例如：用户可能订阅了博客或博客中的特定帖子。 这意味着博客订阅扩展了帖子订阅，并且此数据模型不反映此行为。在这种情况下，我将不得不生成 2 个事件：一个用于博客，一个用于帖子。
将所有事件放在一张表中或将它们拆分到不同的表中是一个好主意吗？无论如何，事件表都会有大量的数据。有更好的想法来组织事件日志记录吗？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
一个表中的子类和单独表中的子类是一个常见问题。
没有“好主意”的答案。两者都是好主意。
一个问题是您将如何查询它们。
如果您很少对所有不同的事件子类型进行联合，并且几乎没有重叠的功能，那么单独的表可能会很好。
如果您经常执行联合式查询，将多个不同的事件子类型组合在一起，或者您有很多重叠的功能，那么单个表可能效果很好。
另一个问题是多态性。
如果您的所有事件子类型都是适当的多态性，那么您的应用程序（和数据库）将使用事件子类型的混合集合。这将引导您到一张表。
如果您的事件子类型非常不同，并且不能多态使用，那么它们应该位于单独的表中。
后果
对于一张表中的所有子类型，您必须对所有子类型不共有的那些属性使用 NULLABLE 列。您还应该有一个列来告诉该行代表哪种子类型。
将多个子类型放入单个表中时，必须有一个鉴别器列来告诉该行应该是哪个子类型。
将子类型放入单独的表中时，您有两种设计。
重复所有表中的公共元素。当共同点很少时执行此操作。
将子类型表连接到父类型表，并将公共元素放在一张表中。当几乎一切都是通用的时，请执行此操作。
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.