我正在创建一个数据库模式，用于技术分析，如收益率最高，赢家价格最高等。我已经检查了问题的答案，例如the design question。从 boe100 的回答中得到了提示，我有一个模型，其中有很多模型，因此：
Symbol - char 6 //primary
Date - date //primary
Open - decimal 18, 4
High - decimal 18, 4
Low - decimal 18, 4
Close - decimal 18, 4
Volume - int
现在这个包含日终（EOD）数据的表将在3年内大约300万行。后来当我得到/需要更多数据时，它可能是2000万行。
前端会询问诸如“在Y天的日期X上给我最高涨价”的请求。这个要求是一个比较简单的要求，因此，我认为这样的时间并不太昂贵。
但是，像“过去10天以前100天作为基线给我最大涨幅”的请求，可能要高出10-100倍。这种请求的结果将是一个浮点数，表示音量增长的次数等。
我有一个选项是为每个这样的结果添加一列。如果用户在20天内要求10天内的体积增加，则需要另一列。这样的列总数可以很容易地超过100，特别是如果我开始添加其他结果作为列，如MACD-10，MACD-100。每个都需要自己的专栏。
这是一个可行的解决方案吗？
另一个选择是我将结果保存在缓存的html文件中并将它们呈现给用户。我在网络开发方面没有太多经验，所以对我来说它看起来很乱;但我可能是错的（ofc！）。这也是一个选择吗？
让我补充一点，我/将使用mod_perl向用户呈现响应。使用perl完成mysql数据库的大部分工作。我希望有1-2秒的响应时间。
答案 0 :(得分：2)
您应该尽可能保持数据规范化，并让RDBMS完成其工作：根据规范化数据高效执行查询。
不要猜测什么会有效或不会有效;相反，仅针对特定的，测量的低效率进行优化，如RDBMS的查询解释器所报告的那样。
优化的有效工具包括粗略的优先顺序：
进一步规范化数据，允许RDBMS自行决定如何最好地回答查询。
重构特定查询以消除查询解释器报告的低效率。这将提供关于如何提高应用程序效率的良好反馈，或者如上所述可能导致更好的关系正常化。
在属性上创建索引，实际上，这些属性将用于大量的事务中。这可能非常有效，但是在维护索引时，这是对大多数写入操作减速的权衡，以便在使用索引时在某些特定的读取操作中获得速度。
创建补充表以保存中间预先计算的结果，以便在将来的查询中使用。这很少是一个好主意，尤其是因为它完全打破了DRY原则;您现在必须提出一种策略，即当存在 no 重复数据时RDBMS将完成其最佳工作时，保持重复信息（原始数据和派生数据）同步。
这些都不涉及在存储主要数据的表格内乱搞。