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
このデータはすべて最初のテーブルから計算できるので、再度保存する必要がありますか? 私がそれを検討している唯一の理由は、計算を実行するデータの行がたくさんあるということです.....
それは、あなたが持っているデータの量と、他のトランザクション要件が何であるかによって異なります.
ソース/OLTP システムがある場合、このデータを複製しても意味がありません。私は MySQL ではなく SQL Server プログラマーですが、他のすべての RDBMS と同様に datepart 関数があるので、日付から週番号を決定するのは簡単だと思います。
ただし、OLAP やレポートを作成する場合は、週レベルの粒度でデータを含む別のテーブルを作成することをお勧めします。これにより、特に関数の出力に対して実行すると通常うまく機能しない集計などのレポートが大幅に高速化されます。
これらは両方とも、データのスケールによって異なります。1 日に何百行もある場合、そのために具体化された週次テーブルを作成する価値はないかもしれません。1 日あたり数万件のレコードがある場合、パフォーマンス上の利点により、おそらく妥当なオプションになります。
あなたはそれが必要かどうか尋ねますか？知るか。それはあなたが持っているディスク容量に依存します。ただし、説明しているのは「昔ながらの」集計テーブルであり、レポートのパフォーマンスを向上させるためによく使用されます。履歴データを扱う場合、データは変化しないため、週ごとの合計などを再計算する必要はありません。
実際、これを行う場合は、柔軟性を高めるために「月次」および「年次」の集計テーブルも定義します。特に、履歴が非常に多い場合はそうです。各期間を比較できるように、データを「標準化」することを検討できます。カレンダーの月と週では取引日数が異なるため、「1 日の平均出来高」などは誤解を招く可能性があります。
本気でやりたいのであれば、ROLAP ソリューションについて調査してください。これは非常に幅広いトピックですが、役に立つかもしれません。
このデータはすべて最初のテーブルから計算できるので、再度保存する必要がありますか?
まとめて保管する必要はありません。すべての集計計算を行うビューを作成し、そのビューにクエリを実行するだけです。
ただし、データの全範囲にわたって多くのレポートを実行する場合は、一度集計して結果を保存するのが理にかなっています。約 4,000 万行から始めます。(3500株×43年×約265日/年)
私があなたの立場なら、データをロードし、週ごとの価格のクエリを作成し、パフォーマンスをテストします。遅すぎる場合は、集計データをテーブルに挿入します。