Web 应用程序中的用户事件订阅

Question

我们正在开发让用户订阅特定事件组的 Web 应用程序。 例如：用户在 blob 中创建评论，所有订阅此博客的用户都应在其列表中包含此事件。

目前，我们正在寻找存储这些数据的数据模型。

从可用性的角度来看，将所有事件存储在一个表中似乎是个好主意：

• 对象（在示例中：注释参考）
• 可订阅对象（示例中：博客参考）
• 引发事件的用户
• 事件类型（如：更新、创建等）

特定用户的订阅事件可以通过 sql 查询收集，该查询将按用户订阅过滤事件。

此数据模型中的问题是可订阅对象可能具有“继承”。例如：用户可能订阅了博客或博客中的特定帖子。 这意味着博客订阅扩展了帖子订阅，并且此数据模型不反映此行为。在这种情况下，我将不得不产生 2 个事件：一个用于博客，一个用于发布。

将所有事件放在一个表中或将它们拆分到不同的表中是个好主意吗？无论如何，事件表将包含大量数据。组织事件日志记录有更好的主意吗？

Answer 1

一个表中的子类和不同表中的子类是一个常见问题。

没有“好主意”的答案。两者都是好主意。

一个问题是您将如何查询它们。

如果您很少合并所有不同的事件子类型，并且几乎没有重叠功能，那么单独的表可能会很好。

如果您经常执行联合式查询，将几个不同的事件子类型组合在一起，或者您有很多重叠的功能，那么单个表可能会很好。

另一个问题是多态性。

如果您的所有事件子类型都是正确的多态，那么您的应用程序（和数据库）将使用事件子类型的混合集合。这会将您带到一个表。

如果您的事件子类型都非常不同，并且不能多态使用，那么它们应该在单独的表中。

后果

对于一个表中的所有子类型，对于并非所有子类型共有的属性，您必须使用 NULLABLE 列。您还应该有一个列来说明该行代表哪个子类型。

将多个子类型放在一个表中时，您必须有一个鉴别器列，该列告诉该行应该是哪个子类型。

将子类型放在单独的表中时，您有两种设计。

• 在所有表格中重复公共元素。在没有共同点的情况下这样做。

• 将子类型表连接到超类型表，并将公共元素放在一个表中。当几乎所有事情都很常见时这样做。