【发布时间】：2012-09-23 03:31:21
【问题描述】：
我有一个应用程序，其中每个“工作修订”都有许多计算 - 这涉及与该修订链接的多行的总和。
我想知道最佳做法是否是：
- 在作业修订中存储“总”数字，以便我们无需汇总即可显示
- 在运行时向用户显示时计算总数
【问题讨论】：
-
如果您的数据库支持物化视图（例如 Oracle）或类似结构，那么这是另一种选择。此类数据库可能会提供针对物化视图的查询重写选项。
标签： sql
【发布时间】：2012-09-23 03:31:21
【问题描述】：
这在很大程度上取决于几个因素，例如：
- 准确性有多重要？在显示图的那一刻，图是否需要完全准确？
- 检索速度有多重要？及时显示数字比准确更重要吗？
- 写作速度有多重要？快速写入每一“行”是否更重要？
- 涉及多少数据？我们是在谈论数百万行还是数百行？
- 多行多久同时更新一次？通常是一次更新多行“作业修订”，还是更有可能一次只涉及一行？
每一种都有不同的取舍，并且有多种选择可以满足每一种的平衡。
- 您可以创建触发器，以在每次插入、更新或删除新行时更新“缓存”总数。这将确保准确性和快速检索，但会减慢写入速度，因为它每次都涉及对“缓存”表的额外更新，而这又涉及行级锁定以确保数字保持准确。锁定会减慢其他操作的速度取决于同一“作业修订”上的其他操作同时发生的频率。
- 您可以只计算每次的值。这可确保值准确，并且插入/更新速度很快，但计算值可能效率低下且速度慢。
- 您可以将值存储在缓存表中，但只能定期更新。这样可以确保读取和写入都很快，但会牺牲准确性。
如果您只处理少数几行，则这些行之间没有太大区别，并且“每次都计算它”就可以了。如果没有实际需要让事情变得更快，则优先计算每次为“更多normal”
一如既往：不要只问一般情况下什么是好的。分析您自己的代码，查看瓶颈在哪里，并倾向于遵循“Don't, yet”规则。
【讨论】：
视情况而定。
如果有方便的方法来计算它，那么你不需要一个可能很昂贵的查询来计算它。预先计算的一个大问题是额外的复杂性，您可能会在维护总计和数据方面变得笨拙。
这是设计上的妥协，所以对于最终的结果没有正确的答案。我要说的是，您应该将总计的预先计算视为一种优化，因此，如果您还不知道需要这样做，那是一种过早的优化。
如果出现问题，您最终可能需要大量工作来整理数据。如果他们因未修复的错误或未填补的空白而步履蹒跚，这是一项重大且持续的工作。
不是你应该或实际上应该急于进入的东西。
【讨论】：