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

Question

我们正在开发将具有用户订阅特定事件组的Web应用程序。 例如：用户在blob中创建一条评论，所有订阅这个博客的用户应该在他们的列表中包含这个事件。

当前，我们正在搜索数据模型来存储这些数据。

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

• 对象（在本例中：评论参考）
• 可订阅对象（在本例中：博客引用）
• 用户生成该事件
• 事件类型（如：更新，创建等）

订阅事件对于特定用户而言，可能会被sql查询收集，该查询将按用户订阅过滤事件。

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

将一个表中的所有事件放在一张表中或者将它们分成不同的表格是一个好主意吗？无论如何，事件表将会有大量的数据。有没有更好的主意来组织事件记录？

Answer 1

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

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

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

如果你很少做所有不同的事件子类型的联合，并且你有几乎没有重叠的功能，那么单独的表就可以很好地工作。

如果你经常做一个联合风格的查询，将几个不同的事件子类型组合在一起，或者你有很多重叠的功能，那么单个表就可以很好地工作。

另一个问题是多态性。

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

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

后果

有了一个表中的所有亚型中，你必须使用空列对于那些不常见的所有亚型属性。你也应该有一个列，告诉哪一行代表的子类型。

将多个子类型放在一个表中时，您必须有一个区分列来判断该行应该是哪个子类型。

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

• 在所有表中重复公共元素。在没有共同点的时候这样做。

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