我知道在之前已经多次询问过这个问题的变体（我已经阅读了它们，其中2个是：1，2），但是我只是不能把我的脑袋包裹在任何感觉像是正确解决方案的地方。
从多对多关系，扇出，多态关联，NoSQL解决方案，消息队列，非规范化以及它们的组合都提出了一切建议。
我知道这个问题非常具有情境性，所以我将简要解释一下：
同时，我最终使用非规范化设置，基本上由一个事件表组成：id，date，user_id，action ，root_id，object_id，object，data。
user_id是触发事件的人
action是行动。
root_id是object所属的用户
object是对象类型。
data包含在用户流中呈现事件所需的最少量信息。
然后，为了获得所需的事件，我只抓住所有行，其中user_id是用户的id，我们正在抓取他们的流。
它有效，但非正规化只是感觉错误。多态关联看起来同样如此。 Fanout似乎介于两者之间，但感觉非常混乱。
通过我对这个问题的全部搜索，并在这里阅读了很多关于SO的问题，我无法点击任何内容并感觉它是正确的解决方案。
任何人都可以提供的任何经验，见解或帮助非常赞赏。感谢。
答案 0 :(得分：2)
我从未处理社交活动Feed，但根据您的描述，它们与维护棘手的业务活动日志非常相似。
就个人而言，我倾向于使用适用活动类型的单独表管理，每种类型的修订/日志表以及后者中的每一个都引用更中心的事件日志表。
后者允许构建feed并且看起来很像你提出的解决方案：event_id，event_at，event_name，event_by，event_summary，event_type。 （event_type字段是包含表或对象名称的varchar。）
您可能不需要维护所有内容的历史记录（肯定这不适合朋友请求而不是销售和库存变动），但保留某种中央事件日志表（除了其他我认为，适用于掌握标准化数据的表格是正确的方法。
通过查看与审核日志相关的问题，您可能会获得一些有趣的见解：
答案 1 :(得分：0)
我认为使用NoSQL / Memcached的组合可能适合您的需求。请参阅此URL以获取更多建议：
http://www.slideshare.net/danmckinley/etsy-activity-feeds-architecture