视图 VS 表 对于“facebook”之类的提要

Posted 2023-04-15

【中文标题】视图 VS 表 对于“facebook”之类的提要

【英文标题】：Views VS Tables For "facebook" like feed

【发布时间】：2010-08-07 15:19:49

【问题描述】：

我目前正在设计一个功能类似于 facebook 提要的仪表板提要。 Feed 将包含以下内容：

通知用户有新用户 显示发送给用户的推荐，收到的推荐 管理员消息 即将举行的活动。

以上每一项都存储在自己的表格中，但在提要页面上，它们应该全部混合在一起。没关系，所以我首先想到的是一张桌子。使用表格，它更易于调试，允许我保留历史数据，并且如果我需要将 if 用于其他目的，例如，如果我们让用户能够使通知变得粘滞，则很容易更改。

所以我和我的经理讨论了我的解决方案，他说使用视图可能会更好，因为 SELECT 占用的资源比典型的删除和插入要少得多。我同意他的观点，因为在每次页面加载开始时，我必须对表格进行清理，删除未使用的记录，删除不再有效的项目，并重新填充更新的数据。现在，如果他们继续点击刷新，将没有工作要做，因此性能影响还不错，但如果 1000 个用户同时访问该站点，如果该表正在填充，则可能会对性能造成巨大影响所有这些用户。

我想我对使用视图的唯一担心是我很喜欢历史数据，而且以后如果用户想要自定义视图，它会更容易；但目前还没有提到这一点，所以性能是目前唯一的问题。

以下是通知需要做的事情：

显示来自多个表的最新信息 这些项目必须按照输入系统的日期混入和排序 其中一些会是粘性的，而另一些则不会基于管理员的决定（这些将暂时静态设置） 能够从列表中删除项目 每个用户都有自己的区域来展示自己的项目。 始终为新用户显示的项目。例如，如果有一条欢迎消息需要在用户首次登录时显示 如果通知超过 100，则删除 100 之后的所有通知，即使通知低于 100，也不要显示它们

这是帮助我完成这项任务的两张表：

通知 - 身份证 - user_id（如果为空，则所有用户都可以查看此项目） - table_pk（此链接到的表的主 ID - 表（此行链接到的表） - 粘性（物品是否有粘性） - date_added（添加日期）

notifications_removed - 身份证 - 通知ID - user_id

现在我有一个填充该表的刷新功能，但我的经理的想法是我们摆脱通知表并将其变为视图。这样做会有好处吗？如前所述，这些项目每次都会刷新，因此性能影响是我的方式将不得不对通知表进行表清理，而视图只是选择并将事物连接在一起。另一方面，我看到的唯一缺点是我将失去通知的灵活性和历史记录，目前这不是一件大事。

【参考方案1】：

非物化视图（mysql 不支持物化视图）与准备好的 SELECT 语句没有什么不同 - 您可以并排运行这两个语句，并且性能相同。应用于视图的简单 WHERE 子句（谓词）可以推送到内部查询中，但这意味着没有数据操作（即：列上的函数、聚合函数等）。

用正在汇总的数据视图替换通知将减轻对表的更新，使系统更加“实时”。您是否需要方便的历史数据？您可以从备份中恢复它（尽管在大量备份中重建数据会很麻烦），或者您可以在数据中添加一个标志，这样删除的数据就不会从表中删除 - 该标志只是控制可见性（但这意味着持有更多数据）。

以前

如果您在另一个问题中提供了更多详细信息，我们可以帮助您优化。通常，您会在可能的情况下缓存数据，因为数据库访问成本很高，但它是决定何时刷新缓存的一种平衡行为。

【讨论】：

是的，我同意数据库之旅很昂贵。无论哪种方式，我都需要去刷新数据，因为它应该是实时的。我已经更新了上面的问题。

所以一般来说，如果我只是查询一堆表而不是存储和拉取，那么使用视图会是一个更好的主意？我想我一直都知道那样会更好。现在我的下一个问题是，您说 SQL 查询在性能方面与视图相同。如果我创建所有这些表的并集并从所有表中进行选择会更容易吗？