我正在设计一个社交网络，想知道我是否走在正确的轨道上。我在网站上有通知，请求和直播。类似于我们现在在大多数网站上看到的内容。要设计这些，我认为这些不是单独的组件，而是它们都从同一个Activity组件中流出来？
系统有一组可能涉及30个对象的200个活动。 40个活动可能有通知，70个可能有提要，10个可能有请求。所以我假设这些将成为活动查找表的一部分 - 活动是否有Feed，Notification，Request as Boolean列。如果是，则为用户显示所有3（Feed，Notification，Request）的默认文本，例如“NAME在照片上发表评论”。另一列将FK添加到对象查找表中以匹配具有活动的对象。
所以基本上我不确定这些是否应该只是活动查找表的一部分，还是有其他设计需要考虑？
一个可能的用例就像通知一样 - 系统可能有40个可用，但用户可能只会选择其中的10个。因此，将有一个单独的用户设置表来保存用户定义的首选项。
答案 0 :(得分：0)
你在做什么听起来对我有用。在这种情况下，活动关系似乎可用。围绕规模的重大问题，但这些可以通过数据库解决方案解决（例如Postgres-XC on Postgres）。
我没有看到改善那里关系设计的明显方法。