database-design - 通知/提要/请求的基本架构设计？

Question

我正在设计一个社交网络，想知道我是否在正确的轨道上。我在网站上有通知、请求和实时订阅源。类似于我们现在在大多数网站上看到的内容。为了设计这些，我假设这些不是单独的组件，而是它们都从同一个 Activity 组件流出？

系统有一组可能涉及 30 个对象的 200 个事件。 40 个事件可能有通知，70 个可能有提要，10 个可能有请求。所以我假设这些将是事件查找表的一部分 - 事件是否有作为 bool 列的提要、通知、请求。如果是，则向用户显示所有 3(供稿、通知、请求)的默认文本，例如“NAME 对照片发表了评论”。另一列将 FK 到对象查找表以匹配对象与事件。

所以基本上我不确定这些是否都应该只是事件查找表的一部分，还是有其他一些设计需要考虑？

一种可能的用例是通知——系统可能有 40 个可用，但用户只能选择其中的 10 个。所以会有一个单独的用户设置表来保存用户定义的首选项。

Answer 1

你在做什么对我来说听起来很理智。在这种情况下，事件关系似乎可用。大问题围绕规模，但这些可以通过 db 解决方案解决(例如 Postgres 上的 Postgres-XC)。

我没有看到改进那里的关系设计的明显方法。