我很想听听你对实现社交活动流的最佳方式(Facebook就是最著名的例子)的看法。涉及的问题/挑战有:
不同类型的活动(张贴，评论..) 不同类型的对象(帖子，评论，照片..) 1-n个不同角色的用户(“用户x回复了用户y对用户Z帖子的评论”) 同一活动项的不同视图(“您评论了..”vs。“你的朋友x评论”vs。"用户x评论说.."3个“评论”活动的表示)
. .还有更多，特别是如果你把它提高到一个高度复杂的水平，比如，把几个活动项目合并成一个(“用户x, y和z评论了那张照片”)。
任何关于模式、论文等关于最灵活、有效和强大的方法来实现这样一个系统、数据模型等的想法或建议都将受到欢迎。
尽管大多数问题与平台无关，但我最终有可能在Ruby on Rails上实现这样一个系统
当前回答
如果您愿意使用单独的软件，我建议使用Graphity服务器，它完全解决了活动流的问题(构建在neo4j图形数据库之上)。
算法已经作为一个独立的REST服务器实现，因此您可以托管自己的服务器来交付活动流:http://www.rene-pickhardt.de/graphity-server-for-social-activity-streams-released-gplv3/
在论文和基准测试中，我展示了检索新闻流只依赖于你想要检索的条目的数量，而没有任何冗余，你会从反规范化数据中得到:
http://www.rene-pickhardt.de/graphity-an-efficient-graph-model-for-retrieving-the-top-k-news-feeds-for-users-in-social-networks/
在上面的链接中，您可以找到屏幕视频和这种方法的基准测试(显示graphity能够每秒检索超过10k个流)。
其他回答
我在几个月前解决了这个问题，但我认为我的实现太基础了。 我创建了以下模型:
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"}
如果你决定用Rails实现，也许你会发现下面的插件很有用:
ActivityStreams: http://github.com/face/activity_streams/tree/master
如果没有其他问题，您将从数据模型和为推拉活动提供的API两方面来研究一个实现。
关于这样的活动流有两个铁路广播:
http://railscasts.com/episodes/406-public-activity(带有gem public_activity的活动提要) http://railscasts.com/episodes/407-activity-feed-from-scratch(从头开始是一样的)
这些解决方案不包括你所有的要求，但它应该给你一些想法。
// 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中选择，加入事件，按时间戳排序。 然后可以对该查询的结果进行过滤和聚合。 使用此模型，您可以在创建后更改事件属性，而不需要额外的工作。
After implementing activity streams to enable social feeds, microblogging, and collaboration features in several applications, I realized that the base functionality is quite common and could be turned into an external service that you utilize via an API. If you are building the stream into a production application and do not have unique or deeply complex needs, utilizing a proven service may be the best way to go. I would definitely recommend this for production applications over rolling your own simple solution on top of a relational database.
我的公司collaboration (http://www.collabinate.com)就是从这种实现中发展出来的，我们在图形数据库上实现了一个可伸缩的高性能活动流引擎来实现它。实际上，我们使用了Graphity算法的变体(改编自@RenePickhardt的早期工作，他也在这里提供了答案)来构建引擎。
如果您希望自己托管引擎或需要特殊功能，其核心代码实际上是非商业用途的开源代码，因此欢迎您查看。
