sql - 存储总值或在运行时求和的最佳实践

Question

我有一个应用程序，其中每个“工作修订”都有许多计算 - 这涉及与该修订链接的多行的总和。

我想知道的是，如果最佳做法是：

1. 在作业修订中存储“总”数字，这样我们就可以在不总结的情况下显示
2. 向用户显示时在运行时计算总数

Answer 1

这在很大程度上取决于几个因素，例如：

• 准确性有多重要？在显示图形的那一刻，图形是否需要完全准确？
• 检索速度有多重要？数字显示的及时比准确更重要吗？
• 写作速度有多重要？快速写入每个“行”是否更重要？
• 涉及多少数据？我们是在谈论数百万行还是数百行？
• 多行多久同时更新一次？通常是一次更新多行“作业修订”，还是更有可能一次只涉及一行？

这些中的每一个都有不同的权衡，并且有多种选择可以满足每种选择的平衡。

• 您可以创建触发器，每次插入、更新或删除新行时更新“缓存”总数。这将确保准确性和快速检索，但会减慢写入速度，因为它每次都涉及对“缓存”表的额外更新，而这又涉及行级锁定以确保数字保持准确。锁定减慢其他操作的速度取决于同一“作业修订”上的其他操作同时发生的频率。
• 您可以每次都计算该值。这确保了值是准确的，并且插入/更新速度很快，但计算值可能效率低下且速度慢。
• 您可以将值存储在缓存表中，但只能定期更新。这确保了读取和写入都很快，但以牺牲准确性为代价。

如果您只处理少数几行，那么这些行之间没有太大区别，并且“每次都计算它”就可以了。如果没有实际需要让事情变得更快，那么每次计算都是首选，因为“更正常”

一如既往：不要只问一般情况下什么是好的。分析你自己的代码，看看瓶颈在哪里，并倾向于遵循“不要，还没有”的规则。

Answer 2

这取决于。

如果有方便的方法来计算它，那么你不需要一个可能很昂贵的查询来计算它。预先计算的一个大问题是额外的复杂性，您可能会因为维护总计和数据而变得笨拙。

这是设计上的妥协，所以对于最终的结果没有正确的答案。我想说的是，您应该将总计的预先计算视为一种优化，因此，如果您还不知道需要这样做，那是一种过早的优化。

如果事情不合时宜，您最终可能需要大量工作来整理您的数据。如果他们因未修复的错误或未填补的差距而步履蹒跚，那么这是一项重大且持续的工作。

不是你应该需要或实际上应该急于进入的东西。