database-design - 事件流/提要，是否非规范化？

Question

我知道这个问题的变体已经被问过很多次(我已经阅读过它们，其中两个是: 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。

它有效，但非规范化感觉不对。多态关联似乎也是如此。扇出似乎介于两者之间，但感觉非常困惑。

通过我对这个问题的所有搜索，并阅读了关于 SO 的众多问题，我只是无法点击任何东西并感觉像是正确的解决方案。

任何人都可以提供的任何经验、见解或帮助是 大大赞赏。谢谢。

Answer 1

我从未处理过社交事件提要，但根据您的描述，它们与维护棘手的业务事件日志非常相似。

就个人而言，我倾向于使用适用事件类型的单独表、每种类型的修订/日志表以及后者中的每一个都引用更中心的事件日志表来管理这种情况。

后者允许构建提要，看起来很像您提出的解决方案:event_id、event_at、event_name、event_by、event_summary、event_type。 (event_type 字段是一个包含表或对象名称的 varchar。)

您可能不需要维护您案例中所有内容的历史记录(当然，这对于好友请求而言不如销售和库存变动更合适)，但需要维护某种中央事件日志表(除了其他适用的表我认为，手头有标准化数据)是正确的方法。

通过查看与审计日志相关的问题，您可能会得到一些有趣的见解:

https://stackoverflow.com/search?q=audit+log