我正在存储从 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
既然这些数据都是从第一个表中可以计算出来的，那是不是需要重新存储呢？我考虑它的唯一原因是有很多行数据正在运行计算.....
【问题讨论】：
标签： php mysql sql database-design
这取决于您拥有多少数据以及您是否有其他交易要求。
如果您有源/OLTP 系统，那么在源/OLTP 系统中复制这些数据是没有意义的。我是一名 SQL Server 程序员，而不是 MySQL，但我想他们像所有其他 RDBMS 一样具有 datepart 函数，因此从日期确定周数是微不足道的。
但是，当您使用 OLAP 或报告时，您可能希望创建另一个表格，其中包含您周级粒度的数据。这将使报告速度更快，特别是对于在针对函数的输出运行时通常表现不佳的聚合之类的事情。
这两者都取决于您的数据规模。如果您每天有数百行，则可能不值得为此创建一个具体化的周表。如果您每天有数万条记录，那么性能优势可能会使其成为一个合理的选择。
【讨论】：
你问有没有必要？谁知道。这取决于你有多少磁盘空间。但是，您所描述的是“老式”聚合表，通常用于提高报告性能。在处理历史数据时，由于数据没有变化，因此无需重新计算诸如每周总计之类的东西。
事实上，如果我这样做，我还会定义“月度”和“年度”汇总表以获得更大的灵活性，尤其是对于如此多的历史。您可以考虑将数据“标准化”，以使每个时期都具有可比性。日历月和周的交易日数不同，因此“平均每日交易量”之类的内容可能会产生误导。
如果您真的想变得花哨，请对 ROLAP 解决方案进行一些研究。这是一个非常广泛的主题，但您可能会发现它很有用。
【讨论】：
既然这些数据都是从第一个表中可以计算出来的，那是不是需要重新存储呢？
没有必要总结和存储。您可以只创建一个执行所有汇总计算的视图，然后查询该视图。
但是，如果您要对所有数据范围运行大量报告，那么将其汇总一次并存储结果是有意义的。您将从大约 4000 万行开始。 （3500股*43年*约265天/年）
如果我站在你的立场上，我会加载数据、编写每周价格查询并测试性能。如果太慢，请将汇总数据插入表格中。
【讨论】：