我很想听听你对实现社交活动流的最佳方式(Facebook就是最著名的例子)的看法。涉及的问题/挑战有:
不同类型的活动(张贴，评论..) 不同类型的对象(帖子，评论，照片..) 1-n个不同角色的用户(“用户x回复了用户y对用户Z帖子的评论”) 同一活动项的不同视图(“您评论了..”vs。“你的朋友x评论”vs。"用户x评论说.."3个“评论”活动的表示)
. .还有更多，特别是如果你把它提高到一个高度复杂的水平，比如，把几个活动项目合并成一个(“用户x, y和z评论了那张照片”)。
任何关于模式、论文等关于最灵活、有效和强大的方法来实现这样一个系统、数据模型等的想法或建议都将受到欢迎。
尽管大多数问题与平台无关，但我最终有可能在Ruby on Rails上实现这样一个系统
当前回答
我在几个月前解决了这个问题，但我认为我的实现太基础了。 我创建了以下模型:
HISTORY_TYPE
ID - The id of the history type
NAME - The name (type of the history)
DESCRIPTION - A description
HISTORY_MESSAGES
ID
HISTORY_TYPE - A message of history belongs to a history type
MESSAGE - The message to print, I put variables to be replaced by the actual values
HISTORY_ACTIVITY
ID
MESSAGE_ID - The message ID to use
VALUES - The data to use
例子
MESSAGE_ID_1 => "User %{user} created a new entry"
ACTIVITY_ID_1 => MESSAGE_ID = 1, VALUES = {user: "Rodrigo"}
其他回答
我认为Plurk的方法很有趣:他们以一种看起来很像谷歌Finance的股票图表的格式提供你的整个时间轴。
想要了解一个社交网络是如何运作的，不妨看看Ning。开发人员页面看起来特别有用。
事件流最大的问题是可见性和性能;您需要将显示的事件限制为只显示该特定用户感兴趣的事件，并且需要保持整理和识别这些事件所需的时间。我建立了一个小型的社交网络;我发现，在小范围内，在数据库中保留“事件”表是可行的，但在中等负载下就会出现性能问题。
对于较大的消息流和用户，最好使用消息传递系统，将事件作为消息发送到单个配置文件。这意味着您不能很容易地订阅人们的事件流，也不能很容易地查看以前的事件，但是当您需要为特定用户呈现流时，您只是呈现了一小组消息。
I believe this was Twitter's original design flaw- I remember reading that they were hitting the database to pull in and filter their events. This had everything to do with architecture and nothing to do with Rails, which (unfortunately) gave birth to the "ruby doesn't scale" meme. I recently saw a presentation where the developer used Amazon's Simple Queue Service as their messaging backend for a twitter-like application that would have far higher scaling capabilities- it may be worth looking into SQS as part of your system, if your loads are high enough.
// one entry per actual event
events {
id, timestamp, type, data
}
// one entry per event, per feed containing that event
events_feeds {
event_id, feed_id
}
创建事件时，决定它出现在哪个提要中，并将这些提要添加到events_feeds中。 要获取提要，请从events_feeds中选择，加入事件，按时间戳排序。 然后可以对该查询的结果进行过滤和聚合。 使用此模型，您可以在创建后更改事件属性，而不需要额外的工作。
我使用了与heyman类似的方法——一个非规范化的表，其中包含将在给定的活动流中显示的所有数据。它适用于活动有限的小型站点。
如上所述，随着站点的增长，它很可能面临可伸缩性问题。就我个人而言，我现在并不担心规模问题。我以后再考虑这个问题。
Facebook显然在扩展方面做得很好，所以我建议你阅读他们的工程博客，因为它有大量的好内容——> http://www.facebook.com/notes.php?id=9445547199
I have been looking into better solutions than the denormalized table I mentioned above. Another way I have found of accomplishing this is to condense all the content that would be in a given activity stream into a single row. It could be stored in XML, JSON, or some serialized format that could be read by your application. The update process would be simple too. Upon activity, place the new activity into a queue (perhaps using Amazon SQS or something else) and then continually poll the queue for the next item. Grab that item, parse it, and place its contents in the appropriate feed object stored in the database.
这种方法的优点是，每当请求特定提要时，您只需要读取一个数据库表，而不是获取一系列表。此外，它允许您维护一个有限的活动列表，因为每当您更新列表时，您可能会弹出最古老的活动项。
希望这能有所帮助!：）
我在几个月前解决了这个问题，但我认为我的实现太基础了。 我创建了以下模型:
HISTORY_TYPE
ID - The id of the history type
NAME - The name (type of the history)
DESCRIPTION - A description
HISTORY_MESSAGES
ID
HISTORY_TYPE - A message of history belongs to a history type
MESSAGE - The message to print, I put variables to be replaced by the actual values
HISTORY_ACTIVITY
ID
MESSAGE_ID - The message ID to use
VALUES - The data to use
例子
MESSAGE_ID_1 => "User %{user} created a new entry"
ACTIVITY_ID_1 => MESSAGE_ID = 1, VALUES = {user: "Rodrigo"}
