问题描述
我有以下课程数据库，每次用户回答一门课程的问题时，这都存储在“Answerings”表中，其中保存了UserID和Questionid以及QuestionoptionsID，问题的数量取决于课程，可以go 每门课程 5 到 50 个问题，每门课程可以有 5 到 500 个用户，系统内置于 Rails
Users Stats Answerings Questions Questionoptions Courses
--------- ------- ------- ------- ------- -------
id id id id id id
fullname user_id user_id course_id question_id name
course_id question_id description option_text
points q_options_id points is_correct
views
calculation1
calculation2
calculation3
然后这些数据必须显示在每门课程的报告中，在那里我显示所有回答的用户，计算获得的总分，重复问题的数量，以及我必须计算与该课程相关的另外 3 个字段公司的业务逻辑，由正确和错误答案的数量和用户的知识生成。
当表少于50个用户时，报表生成速度较慢，因为每个用户计算4到5个字段。
我的解决方案是创建一个名为“Stats”的表，该表与“Users”表是 1 比 1 的，此信息是在此人由后台服务回答时计算的。
这对课程生成报告的影响很大，因为它不再计算 5 到 6 个字段，只计算“STATS”表并且只显示之前已经计算过的字段。
问题是这个解决方案是正确的吗？，或者我应该在不使用表“统计”的情况下进行优化
解决方法
存储计算的总数可以被认为是缓存。像这样缓存计算意味着您必须开始处理使计算保持最新并担心何时不是最新的。从长远来看，这种模式可能会导致大量工作。另一方面，始终计算总数意味着您将始终可以使用新的计算方法。
我见过人们存储计算来解决性能问题，当计算由于其复杂性或基于查询的复杂性而需要很长时间时。这是开始考虑像这样缓存结果的一个很好的理由。
您是否尝试过运行一些查询来发现有多少（如果有）预先计算的值是错误的或过时的？这将比模糊的“它更快/不，它不算数”的讨论更有分量，很少看到明显的赢家。
但它可以给你一些优点。例如，如果您有很多用户并且用户称这些值计算量很大，那么偶尔计算它们可能是更有利可图的策略。它将节省您的服务器资源。
您现在真正的问题是“什么对您更有效？每次计算值还是偶尔计算一次并存储在数据库中？”