我对数据库没有太多经验,所以我不知道哪个更适合长期性能,更好的练习等.
这是我的(假设的)案例:假设您有一个客户信息数据库和每个采购订单的历史记录.您想要跟踪每个客户的购买量.我可以想到两种计算方法:
1)每次需要时只需执行SUM().这是一个简单的解决方案,但关注的是该数据库可能已有20年历史,每个客户都有数万行.随着越来越多的客户购买被添加到数据库中,SUM()操作将需要更长的时间来计算.
2)将总和缓存在客户信息表中,每次进行新的购买(更新,删除等)时,都要更新此缓存.这样,无论有多少采购订单,计算时间都不会增加.缺点是,这是一个不太灵活的解决方案(只有所有行的总和,每月总和的数额？其他间隔？等); 这个缓存的值可能会以某种方式与实际总数不同步(技术上不应该发生,但它可能会)
那么我应该为此做些什么呢？我知道我不应该存储任何我可以根据数据库中已有的东西来计算的东西,但是我的一部分并不喜欢这种类型的计算会在时间上变得更糟的事实,并且有一些优雅的选择2.
在数据库术语中,选项2中没有优雅 - 如果您的数据库变得非常庞大,那么您可能会将其视为最后的手段 - 对于新手第一次设置它不太可能发生(但可能).
维持总数会有很多工作要做; 你会永远处理这个问题:"为什么细节不能与总数相加？"
选择1,直到你证明你不能.在大多数情况下,这将是很长一段时间.
您在选项#2 中描述的是过早优化的情况。使用所有购买的 SUM() 将工作很长时间（数年）。当（如果）您开始看到此功能降级时，您可以向数据库添加索引或总计表以加快速度。当一个简单的解决方案存在时，不要把事情复杂化。
当然，真正的解决方案是用 20 年的虚构数据尝试这两种解决方案，看看是否有任何真正的区别。我怀疑没有。
| 归档时间： |
|
| 查看次数： |
640 次 |
| 最近记录： |