通知/供稿/请求的基本模式设计？

我正在设计一个社交网络，并想知道我是否在正确的轨道上。我在网站上有Notifications，Requests和Live Feed。类似于我们目前在大多数网站上看到的情况。为了设计这些，我假设这些不是单独的组件，而是它们全部从相同的Activity组件流出来？通知/供稿/请求的基本模式设计？

系统有一组说200活动可能涉及30个对象。 40项活动可能有通知，70项可能有供稿，10项可能有请求。因此，我认为这些将成为活动查找表的一部分 - 活动是否具有Feed，Notification和Request作为布尔列。如果是，则默认文本显示给所有3（Feed，Notification，Request）给用户，如“NAME评论照片”。另一列将FK添加到对象查找表中，以将对象与活动进行匹配。

所以基本上我不确定这些应该全部是活动查找表的一部分还是有其他一些设计要考虑？

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

来源

2010-11-01 tony23

一个比较模糊的问题，在“社交网络”/“数据库”/“设计”中有这么多相关的问题...... – pascal 2011-01-28 06:28:38

基于您的设计和规则的简单性，跳过DBMS。这太过分了（我是经典DBMS的忠实粉丝）。现在学习卡桑德拉。通知可以快速添加和删除，并且可以很好地扩展。否则，我认为这里没有足够的信息来真正澄清你正在尝试做什么，但我正在冒出一个猜测。 – Horus 2011-04-18 14:29:38

@Horus：我不同意。你不应该因为它们太简单而使事情变得更复杂。一个简单的数据库层允许他专注于更重要的问题，如创新功能。 – 2011-11-30 18:28:01

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

我没有看到一个明显的方法来改善那里的关系设计。

来源

2012-09-05 10:26:00

通知/供稿/请求的基本模式设计？

回答

相关问题