• ベストアンサー

在庫管理のデータベース

こんにちは。どのカテゴリーで質問すればよいのか わからなかったのですが、データベースの仕様について 悩んでおります。 在庫の受払いのデータベースを作ろうとしています。 受、払それぞれにデータを日ごとに入力し、最終的に 下記の様な形で月ごとに合計するつもりです。 前月残|受|払|当月残 また、日々の詳細についても逐次見られる様にしたいと考えてます。 こういった場合、前月残から当月算残までを1レコードにまとめる (まとめ方もよくわかりませんが)方がよいのか、受、払それぞれの レコードから表示する時だけデータを持ってくるのがよいのか、わから ず悩んでおります。 申し訳ありませんが、ご助言頂ければ幸いです。 よろしくお願いします。

質問者が選んだベストアンサー

  • ベストアンサー
  • O_cyan
  • ベストアンサー率59% (745/1260)
回答No.3

>受、払それぞれにデータを日ごとに入力 >日々の詳細についても逐次見られる様にしたい 通常ではテーブルとして *在庫テーブル(商品一覧テーブル) *取引先テーブル(販売先等ある場合) *仕入先テーブル(仕入先等ある場合) *入出庫テーブル(受入・払出を同一テーブルで行う場合:受入・返品・払出は区分などを使い入出庫テーブルで済ませる。) が必要です。 受入・返品・払出を別テーブルで管理するならば最低5つのテーブル。 でしょうか。 欲を言って入出庫テーブルのバックアップテーブルと月次更新時の在庫数を年月数と共に保存する在庫バックアップテーブル。 *1ヶ月終わったら入出庫テーブルのレコードをバックアップに移し日々使用するテーブルを軽くするため。在庫のバックアップは年月数と共に月次更新時にバックアップを取れば1商品毎の年間推移等が簡単に把握できるレコードが出来るため。 できれば欲をだした構成にした方が後々楽だと思います。 在庫テーブルの更新は月次処理で充分。 デイリー:受入・返品・払出の発生に伴い入力する。 その際、受入・返品・払出が一つのテーブルで処理していれば同一フォームで区分等の変更により入力処理できる。(入力業務の簡易化) 日々の在庫数確認は在庫テーブルの数量と入出庫テーブルのレコードを集計しリアルタイムに在庫数量を表示する。(入出庫のテーブルを先の理由等で当月分処理だけのレコードにしておけば日付での抽出をしなくてすむため集計が少しでも早くなる。) 月次:入出庫テーブルを集計し在庫テーブルのレコードと合算し在庫テーブルの数量を更新する。更新後在庫テーブルのバックアップテーブルへ各レコードを月末の日付データと共に追加してバックアップを取り在庫テーブルは翌月開始数量となる。 こんな感じでしょうか。 >前月残から当月算残までを1レコードにまとめる方がよいのか >受、払それぞれのレコードから表示する時だけデータを持ってくるのがよいのか 1レコードにまとめてもデータベースの意味がありません。データベースとして一番効率の良いテーブル(上記の様な感じのDB)の構築をするのがベストです。

ken1low
質問者

お礼

”受入・返品・払出は区分などを使い入出庫テーブルで済ませる”と 言うことですね。大変参考になりました。ありがとうございました。

その他の回答 (2)

  • ngsvx
  • ベストアンサー率49% (157/315)
回答No.2

1ヶ月分をまとめたレコードを作るかどうかは、データ量によって判断することになるでしょう。 しかしそれは性能改善ということで行うべきもので、十分な性能がでるのならば正規化の考え方からいってやらない方がいいものです。 私なら次のようにすると思います。 入出庫明細テーブル ・明細ID ・商品ID ・日時(システム導入前の切替用残高は0にしておく) ・入出庫区分 ・取消区分 ・数量(在庫が増える場合はプラス、減るならマイナスにする) こうしておけば、残高は日付で選択したレコードの「数量」の合計で計算できます。

ken1low
質問者

お礼

大変ありがとうございました。

  • ymmasayan
  • ベストアンサー率30% (2593/8599)
回答No.1

将来、日々の詳細まで見られるようにするのであれば「件」ごとのレコードに しておくといいでしょうね。 年月日、時間、受払い区分、取引明細 でしょうか。 データベースの設計で大事な原則が3つあります。 1.1つのレコードの中に繰り返し部分を作らない。 2.同じデータを複数のレコードにダブって持たない。 3.必要な時に計算できるデータはデータベースに持たない。 理由は、1はデータ抽出が難しい。2,3はデータ修正をかけたときに矛盾を 発生する恐れがある。またデータ修正が簡単にできる。等の理由です。 ということで、設計の指針は 1.取引レコード、需要家マスタ、商品マスタ・・・と分ける。 2.1か月分を1レコードにまとめることなどはしない。 ということになりましょうか。 なお、詳しいことは「データベース 正規化」でお調べになるといいでしょう。 それと、データベースでどんなことが出来るかは「SQL」「クエリー」等で 検索してみてください。

ken1low
質問者

お礼

データベース 正規化で調べたところいろいろとありました。 大変ありがとうございました。

関連するQ&A