Question

我存储了从1970年到现在的3500种不同股票的价格历史数据（每天都有cron作业运行以更新它）。

存储此数据的最佳方法是什么？它将用于根据每日数据和每周数据运行计算。目前我将其存储为：

stock_id, date, closing_price, high, low, open, volume

由于我也想要每周价格，我应该制作一个单独的表来存储：

stock_id, week_end_date, weekly_closing_price, weekly_high, weekly_low, week_open_price, average_daily_volume, total_weekly_volume

由于这些数据都可以从第一张表中计算出来，是否有必要再次存储？我正在考虑的唯一原因是有很多行数据要运行计算.....

Answer 1

这取决于您拥有的数据量以及您的其他交易要求是什么。

如果您有源数据/ OLTP系统中的数据，则没有任何意义。我是一个SQL Server程序员，而不是MySQL，但我想他们有像所有其他RDBMS一样的datepart函数，所以从一个日期确定一个星期数是微不足道的。

但是，当您进入OLAP或报告时，您可能希望以您的周级粒度创建另一个包含数据的表。这将使报告更快，特别是对于像聚合这样的东西，这些聚合通常在对函数输出运行时表现不佳。

这些都取决于您的数据规模。如果你每天有数百行，那么为此做一个物化的每周表可能是不值得的。如果你每天有成千上万的记录，那么性能优势可能会使它成为一个合理的选择。

Answer 2

你问是否有必要？谁知道。这取决于您拥有多少磁盘空间。但是，您所描述的是“老式”聚合表，通常用于提高报告性能。在处理历史数据时，无需重新计算每周总计等事项，因为数据不会发生变化。

事实上，如果我这样做，我还会定义“月度”和“年度”汇总表以获得更大的灵活性，特别是对于这么多的历史。您可以考虑以每个时期具有可比性的方式“标准化”数据。日历月份和周数具有不同的交易日数，因此“平均每日交易量”之类的内容可能会产生误导。

如果您真的想获得幻想，请对ROLAP解决方案进行一些研究。这是一个非常广泛的主题，但您可能会发现它很有用。

Answer 3

由于这些数据都可以从第一张表中计算出来，是否有必要再次存储？

总结并存储它并非必要。您只需创建一个执行所有摘要计算的视图，然后查询视图。

但是，如果您要对所有数据进行大量报告，那么将它汇总一次并存储结果是有意义的。你将从大约4000万行开始。（3500股* 43年*约265天/年）

如果我在你的位置，我会加载数据，编写每周价格的查询，并测试性能。如果速度太慢，请将摘要数据插入表格中。