1年分の履歴をデータベースにするには

質問

単純な質問ですみません。

現在、商品の名前や価格・在庫数を商品テーブルに記録しています。

この商品の価格や在庫数の1年分（365日分）の履歴をデータベースに記録したいのですが、通常はどのような設計になるのでしょうか？

価格テーブルや在庫テーブルを作って356日分のカラムを作るのが普通ですか？

あと、商品データベースには商品テーブルが一つだけあります。
もし上記のように価格テーブル、在庫テーブルを作るとしたら商品データベースの中に作るのでしょうか？
それとも価格データベースの中に価格テーブル、在庫データベースの中に在庫テーブルを作るのでしょうか？
長所・短所などがありましたら教えてください。

どうぞよろしくお願い致します。

回答No.2

Siegrune · ベストアンサー

>この商品の価格や在庫数の1年分（365日分）の履歴をデータベースに記録したいのですが、通常はどのような設計になるのでしょうか？

例えば、
価格：
価格テーブル
商品コード、適用開始日、価格　
（適用終了日はあっても可：通常は次の適用開始日の前日なのであまり持たない）

※価格が取引先によってまちまちな場合は、価格テーブルに取引先コードがはいっていたり・・・。

在庫：
あまり、日単位の在庫数を持っているのを見たことがない。
元帳テーブル
商品コード、（在庫場所）、年月、月初在庫数
入出庫テーブル
年月日、（入出庫場所）、商品コード、入出庫数
入庫と出庫別々で持つため最大で２レコード持つ。

※毎日の在庫は、上記２テーブルより集計。

★目的によってどういうテーブルを用意するかは変わってきておかしくないので、
例えば、在庫の適正水準算出のために必要な帳票専用のテーブルとして、
年月日、商品コード、在庫数のテーブルがあってもおかしいとは言いませんが、
このテーブルは更新するのが面倒なんです。
⇒例えば、過去日付の入庫を訂正したら・・・その日以降の全データを修正しないといけません。

注：どこまで管理しているかにもよります。
質問文の内容では、入庫数や出庫数は管理していない、単に一日の終わりに在庫数を入力しているだけ
とも考えられます。
これなら、年月日、商品コード、在庫数のテーブルでいいと思われます。
（というより他の持ち方ができない）

データベースを分けるかどうかは、どちらでもいいでしょう。
商品属性なので、商品データベースに含めてもいいし、
在庫属性なので、在庫データベースを別に作ってもいいし、
データベースの容量との関係で問題がなければわかりやすいと思うほうでいいでしょう。

お礼

お礼が遅れて申し訳ございませんでした。
いろいろアドバイスいただけて助かります！

＞このテーブルは更新するのが面倒なんです。
＞例えば、過去日付の入庫を訂正したら・・・その日以降の全データを修正しないといけません。

たしかにそのとおりですね。過去のデータをデータベース内で配置変えするのは無駄ですしね。

＞質問文の内容では、入庫数や出庫数は管理していない、単に一日の終わりに在庫数を入力しているだけとも考えられます。

はい、入庫数や出庫数は管理しません。

＞これなら、年月日、商品コード、在庫数のテーブルでいいと思われます。

これはNo1さんと同じように「年月日のテーブルに商品コードと在庫数のカラムで良い」という意味でしょうか？

回答No.1

yambejp

＞価格テーブルや在庫テーブルを作って356日分のカラムを作るのが普通ですか？

これはあり得ない

条件として、特定の日付には同じ商品がダブらないということでよいですか？
（一日なんども価格がかわるとか在庫数がかわるということではない？）

であれば商品テーブルに正規化された商品情報をいれ
日ごと商品管理テーブル的なものをつくって、日付と商品コードでユニーク属性をつけて

日付,商品コード,価格,在庫
を追記していく方式が良いと思います。
価格テーブル、在庫テーブルなど細分化する必要はないと思います

お礼

ありがとうございます！

＞日ごと商品管理テーブル的なものをつくって、日付と商品コードでユニーク属性をつけて

そのようにするのですね。
10万件くらいあるので1つのテーブルでもけっこうな大きさになりそうですがやってみます。
助かりました！