mysql - 经常性的数据需求——自动查询，还是直接在SQL中存储数据？

Question

这是一个简单的问题，尽管标题听起来很复杂。

假设我将来自一堆应用程序的数据存储到一个中央数据库/数据仓库中。这是相当精细的数据——例如，各种指标的每日摘要。

但是，我知道在前端我也会经常显示这些数据的每周和每月汇总。

一个想法是让脚本语言在查询 SQL 数据库后为我执行此操作 - 但这似乎效率极低。

第二个想法是在数据库中拥有代表业务周和月的 View - 这可能是最好的方法。

但我的最终想法是——SQL 客户端难道不能简单地运行一个查询，将所有每日数据聚合成几周(或几个月)并将它们存储在一个单独的表中吗？这样做的优点是，它会减少任何用户的查询时间，因为所有查询工作都是在加载/按下网站或按钮之前完成的。即使有了 View ，我猜想只要查询 View 就必须进行聚合计算。

将几周/几个月的查询汇总甚至每天一次(而不是每次加载网站时)的唯一缺点是它不会是最新的/可能反射(reflect)不一致。

当谈到这个更大的问题时，我并不是真正的专家——有人有什么想法吗？谢谢

Answer 1

这取决于您尝试创建的用户体验。

用户群在观看本月统计数据时是否希望用一根手指按 F5 键来观看每月汇总数据？为了涵盖这种情况，您可能需要一个带有条件的 View ，该 View 始终显示一个与 getdate() 相关的窗口。请记住，良好的索引策略和查询设计应该可以将这种方法的影响降至几乎为零。

用户是否期望获得不包含今天数据的信息数据？通过将数据聚合到新表中的每晚作业，可能会获得更高的性能。

不过，在所有场景中，我不建议手动聚合。沿着这条路会出现意想不到的错误和异常，这些错误和异常确实可以通过良好的 SQL 语句来处理。聚合是所有 DBMS 的重要组成部分，让他们的软件处理它并在应用程序的其余部分上工作。