我们正在开发让用户订阅特定事件组的 Web 应用程序。例如：用户在 blob 中创建评论，所有订阅此博客的用户都应在其列表中包含此事件。
目前，我们正在寻找数据模型来存储这些数据。
从可用性的角度来看，将所有事件存储在一个表中似乎是一个好主意：
特定用户的订阅事件可能由 sql 查询收集，该查询将按用户订阅过滤事件。
此数据模型中的问题是可订阅对象可能具有“继承”。例如：用户可能订阅了博客或博客中的特定帖子。这意味着博客订阅扩展了帖子订阅，并且此数据模型不反映此行为。在这种情况下，我将不得不产生 2 个事件：一个用于博客，一个用于发布。
将所有事件放在一张桌子上或将它们分成不同的桌子是个好主意吗？无论如何，事件表将包含大量数据。组织事件日志记录有更好的主意吗？
一个表中的子类和不同表中的子类是一个常见问题。
没有“好主意”的答案。两者都是好主意。
一个问题是您将如何查询它们。
如果您很少合并所有不同的事件子类型，并且几乎没有重叠的功能，那么单独的表可能会很好地工作。
如果您经常执行联合式查询，将几个不同的事件子类型组合在一起，或者您有很多重叠的功能，那么单个表可能会很好地工作。
另一个问题是多态性。
如果您的所有事件子类型都是正确的多态，那么您的应用程序（和数据库）将使用事件子类型的混合集合。这会将您带到一个表。
如果您的事件子类型都非常不同，并且不能以多态方式使用，那么它们应该位于单独的表中。
结果
对于一个表中的所有子类型，您必须对并非所有子类型共有的属性使用 NULLABLE 列。您还应该有一列告诉该行代表哪个子类型。
将多个子类型放在一个表中时，您必须有一个鉴别器列，它告诉该行应该是哪个子类型。
将子类型放在单独的表中时，您有两种设计。
在所有表格中重复公共元素。当共同点很少时这样做。
将子类型表连接到超类型表，并将公共元素放在一个表中。当几乎所有事情都很常见时，请执行此操作。