各商品の時間ごとの値段をデータベースにいれたい

Question

いつもお世話になっております。

ECサイトの管理をしており、商品はそれぞれの担当に値段の変更の権限を与えております。
各商品の値段の推移グラフを作りたく、1日2回任意の時間で値段を抽出しています。

商品ごとにテーブルを作り、テーブル内で取得時間と値段のカラムを作る場合だと
現在商品数は2000ほどあるので、2000ものテーブルを作ることになってしまいます。
大量のデータを時間ごとに扱う場合、どのようにテーブルを作るのがベストでしょうか？

最終的にpythonでグラフの出力をするのですが、
イメージとしては株の値段の推移のグラフをろうそく足のグラフではなく
折れ線グラフに変えたようなものを作成予定です。

現在はCSVで管理しており、
商品コード、取得時間、値段を1つのファイルで管理しています。
1回ごとにファイルを変えているので1日で2ファイルずつ作成しています。

アドバイスよろしくお願いいたします。

Comments

[q_sane_q]

商品ごとにテーブルのはBADだと思いますが、「取得時間」のカラムという表現も気になります
「変更時間」ではなくてですか？

[c_php]

すいません。私が値段を取得しているので取得時間という表現をしていました。実際の変更時間は不明です。

[c_php]

また、変更回数も不明です。ただ、急激な値段の変更は禁止しているので日によって競合他社との兼ね合いで値段が上下しています。そのため大体の値段の推移をみるためにグラフを作ることにしました。

[hihijiji]

変更の履歴(ログ)を取っているなら、そこからクエリで求めることをお勧めします。
履歴を取ってないなら取るようにすることをお勧めします。

[c_php]

それぞれの担当ベースで値段を変更した際の履歴は持っていると思いますが、私への提出はファイルが多すぎるのでしていません。

Answer 1

・商品コード、商品名を持つテーブルを用意。PRIMARY KEYは商品コード。

・商品コード、時間帯(DaTETIME型)、値段を持つテーブルを用意。PRIMARY KEYは商品コード、時間帯(DaTETIME型)。

Comments

[c_php]

ご回答ありがとうございます。抽象的な質問で申し訳ないのですが、頂いたアドバイスでは1日に4000レコードずつ増え、1年で1460000レコードになると思うのですが、SQLの応答時間って結構かかるものでしょうか？（スペックによるとは思いますが。。。）

[Orlofsky]

1つのテーブルで40億レコード以上のデータを扱ったことがあります。
SELECTの内容によりますが、適切なインデックスが設定してあればそこそこのレスポンスを期待できます。
サイジングの問題もありますから、データの保存期間は決めておきましょう。

[c_php]

ご返答ありがとうございます。一度頂いた内容からDBを作ってみます。