一切都被建议从许多关系,到多态关联,Nosql解决方案,消息队列,非正规化和它们的组合.
我知道这个问题是非常情况的,所以我将简要解释一下我的：
许多活动引发许多事件.
>用户可以按照其他用户的活动(他们触发的事件).
>最需要的活动将是最近的事件.
>需要查看过去事件的能力.
>通过日期描述排序不需要对Feed进行排序或搜索.
>可扩展性是一个问题(性能和可扩展性).
同时,我结束了一个非规范化设置,基本上由一个由id,date,user_id,action,root_id,object_id,object,data组成的事件表组成.
user_id是触发事件的人员.
行动就是行动.
root_id是对象所属的用户.
对象是对象类型.
包含在用户流中呈现事件所需的最少信息量的数据.
然后为了获得所需的事件,我只是抓住所有的行,其中user_id是正在抓取的流被跟随的用户的id.
它的工作,但非正规化只是感觉错误.多态关联似乎也是如此.扇出似乎在两者之间,但感觉很杂乱.
随着我在这个问题上的所有搜索,并且在这里阅读了许多问题,我根本无法点击任何东西,感觉到正确的解决方案.
任何人可以提供的任何经验,洞察力或帮助都非常感激.谢谢.
解决方法
就个人而言,我倾向于使用单独的表来管理适用的活动类型,每种类型的修订/日志表,以及每个更新中央事件日志表的引用.
后者允许构建Feed,并且看起来像您提出的解决方案：event_id,event_at,event_name,event_by,event_summary,event_type. (event_type字段是包含表或对象的名称的varchar.)
您可能不需要维护您的案例中的所有内容的历史(肯定这不适合于朋友的请求而不是销售和库存变动),而是维护某种中央事件日志表(除了其他适用的表有正确的数据在手)是,我认为,正确的方法.
您可以通过查看审核日志相关问题获得一些有趣的见解：
