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

时间:2009-10-15 10:05:55

标签: database-design events datamodel

我们正在开发Web应用程序,用户可以订阅特定的一组事件。 例如:用户在blob中创建注释,订阅此博客的所有用户都应在其列表中包含此事件。

Currenly,我们正在搜索数据模型来存储这些数据。

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

  • 对象(在示例中:注释引用)
  • 可订阅对象(在示例中:博客参考)
  • 产生该事件的用户
  • 事件类型(如:更新,创建等)

特定用户的订阅事件可能由sql查询收集,该查询将按用户订阅过滤事件。

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

将所有事件放在一个表中或将它们拆分成不同的表是不是一个好主意?无论如何,事件表将拥有大量数据。是否有更好的想法来组织事件记录?

1 个答案:

答案 0 :(得分:1)

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

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

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

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

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

另一个问题是多态性之一。

如果所有事件子类型都是正确多态的,那么您的应用程序(和数据库)将使用事件子类型的混合集合。这会引导您进入一个表格。

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

<强>后果

对于一个表中的所有子类型,必须对所有子类型不常见的属性使用NULLABLE列。您还应该有一个列,告诉该行代表哪个子类型。

当在一个表中放置多个子类型时,必须有一个discriminator列来告诉该行应该是哪个子类型。

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

  • 在所有表格中重复共同元素。如果没有共同点,请这样做。

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