web-dev-qa-db-ja.com

在庫データベースに最適な構造

インベントリ用に小さなデータベースを作成したいのですが、構造の選択に問題があります。在庫は一日の終わりに毎日更新されます。

私が直面している問題は次のとおりです。

私の製品のテーブルがあります。

id, name, price, quantity.

今、私は私の販売のための別のテーブルを持っていますが、私の問題があります。どのようなフィールドが必要ですか。結局のところ、次のようなレコードを保存したいと思います。

20       product_x       $ 5,00         $ 100,-
20       product_y       $ 5,00         $ 100,-
20       product_z       $ 5,00         $ 100,-
20       product_a       $ 5,00         $ 100,-
-------------------------------------------------
                                        $ 400,-

それで、これを販売記録でどのようにモデル化しますか？製品IDのコンマで区切られた連結レコードを作成するだけですか。

または、これを正しい方法でモデル化する別の方法があります。

databasestructure
15
Saif Bechan

1日1アイテムあたり1行のテーブルがあります。日付、アイテムID、販売数量、および販売価格を保存します（これは製品テーブルにも含まれていますが、これを保存します-変更された場合、保存時に実際に販売した値）。クエリでは、1日あたりの合計と1日あたりの合計を計算できます。

テーブル：

create table product (
  id integer primary key,
  name varchar(100) not null,
  price decimal(6,2) not null,
  inventory integer not null
);

create table sale (
  saledate date not null,
  product_id integer not null references product,
  quantity integer not null,
  price decimal(6,2) not null,
  primary key (saledate, product_id)
);

当日の報告：

select s.product_id, p.name, s.quantity, s.price, (s.quantity * s.price) as total
from product p, sale s
where p.id = s.product_id
and s.saledate = date '2010-12-5';

すべての日に関するレポート：

select saledate, sum(quantity * price) as total
from sale
group by saledate
order by saledate;

要約行を含む、すべての日にわたる素晴らしいマスターレポート：

select *
from (
    (select s.saledate, s.product_id, p.name, s.quantity, s.price, (s.quantity * s.price) as total
    from product p, sale s
    where p.id = s.product_id)
  union
    (select saledate, NULL, 'TOTAL', sum(quantity), NULL, sum(quantity * price) as total
    from sale group by saledate)
) as summedsales
order by saledate, product_id;
9
Tom Anderson

これは多くの側面をサポートするモデルであり、

  1. サイト、ロケーション、倉庫などをサポート.
  2. 分類とグループ化をサポート
  3. 一般的な製品のサポート（例：「卓上時計」および特定の製品「Citizen C123 Multi Alarm Clock」）
  4. ブランドバリアントもサポート（さまざまなメーカーによる）
  5. CSM（色/サイズ/モデルのサポート）があります。 Bata Sandles（カラー45インチブルーカラー）
  6. シリアル付きの製品インスタンス（TV、冷蔵庫など）
  7. ロット管理/シリアル番号によるバッチ管理。
  8. パックサイズ/ UOMおよびUOM変換
  9. メーカー、ブランド、サプライヤー
  10. トランザクションテーブルの例も含まれています（注文書）
  11. 課題、送金、調整など、他の多くのトランザクションタイプがあります。

これがお役に立てば幸いです。各テーブルについてさらに情報が必要な場合はお知らせください。

乾杯...！！！

Wajira Weerasinghe。

サイト

  • id
  • site_code
  • サイト名

倉庫

  • id
  • site_id
  • 倉庫コード
  • 倉庫名

アイテムカテゴリ

  • id
  • category_code
  • 種別名

アイテムグループ

  • id
  • group_code
  • グループ名

ジェネリック製品

  • id
  • 一般名

製品

  • id
  • 製品コード
  • category_id
  • group_id
  • brand_id
  • generic_id
  • model_id/part_id
  • 商品名
  • 製品説明
  • product_price（現在のレート）
  • has_instances（y/n）
  • has_lots（y/n）
  • has_attributes
  • default_uom
  • パックサイズ
  • average_cost
  • single_unit_product_code（パック用）
  • dimension_group（次元を指す）
  • ロット情報
  • 保証期間（一般的ではない）
  • アクティブです
  • 削除された

商品属性タイプ（色・サイズ等）

  • id
  • 属性名

product_attribute

  • id
  • 製品番号
  • attribute_id

商品属性値（この商品->赤）

  • id
  • product_attribute_id
  • 値

product_instance

  • id
  • 製品番号
  • instance_name（製造元が指定）
  • シリアルナンバー
  • brand_id（このブランドです）
  • stock_id（qih、場所などを指す株式レコード）
  • ロット情報（lot_id）
  • 保証期間
  • 商品属性値ID（該当する場合）

製品ロット

  • id
  • lot_code/batch_code
  • date_manufactured
  • date_expiry
  • 商品属性値ID（該当する場合）

ブランド

  • id
  • manufacturer_id
  • brand_code
  • ブランド名

ブランドメーカー

  • id
  • メーカー名

株式

  • id
  • 製品番号
  • warehouse_id、zone_id、level_id、rack_idなど.
  • 手元の数量
  • 商品属性値ID（該当する場合）[4つの赤い色のアイテムなどがあります]

製品価格レコード

  • 製品番号
  • from_date
  • product_price

注文書ヘッダー

  • id
  • supplier_id
  • 購入日
  • 合計金額

注文書ライン

  • id
  • po_id
  • 製品番号
  • 単価
  • 量

サプライヤー

  • id
  • supplier_code
  • サプライヤ名
  • supplier_type

product_uom

  • id
  • uom_name

product_uom_conversion

  • id
  • from_uom_id
  • to_uom_id
  • conversion_rule
39
Wajira Weerasinghe

インベントリはモデル化がかなり複雑になる可能性があります。まず、支払った金額に基づいて、手持ちの在庫の値を伝える必要があることを理解する必要があります。つまり、現在の価格に更新された製品テーブルを信頼することはできません。このようなテーブルを使用して何を売るかを理解するのに役立つ場合がありますが、倉庫内の各アイテムに対して支払った実際の価格を知る必要があるのには、税務上の理由があります。

したがって、最初に製品テーブルが必要になります（この中に日付列が更新されていることを確認したい場合があります。価格が古くなっているように見える場合に便利です）。

次に、各部品の実際の倉庫の場所と購入時の価格を格納するテーブルが必要です。アイテムが十分に大きい場合、各アイテムを個別にマークして、何が取り出されたかを知る方法が必要です。通常、人々はそのためにバーコードを使用します。このテーブルを更新して、販売時に部品がなくなったことを記録する必要があります。私はレコードを非アクティブにして、そのレコードへの販売データへのリンクを設定することを好むので、私が支払った金額と各部品を販売した対象を正確に把握しています。

販売には少なくとも2つのテーブルが必要です。 1つは販売に関する一般的な情報、顧客名（このデータを取得するためにほとんどの場合、顧客テーブルも必要です）、日付、出荷先などです。

次に、注文の各ラインアイテムのレコードを含む販売詳細テーブル。パーツ、色、サイズ、数量、価格について必要なすべてのデータを含めます。これは非正規化ではなく、履歴データを格納しています。あなたがやりたくないのは、この表への最初のエントリ以外のすべてについて、製品表の価格に依存することです。前日に製品の価格が変更されたため、販売レポートを作成したくないが、数値が間違っている場合。

会計士や税の専門家に相談せずに在庫データベースを設計しないでください。また、内部統制についてもいくつか読む必要があります。データベース内の内部統制に関する作業を行っていない、発見されていない会社から盗むのは簡単です。

1
HLGEM

販売をトランザクションとしてモデル化してみてください-「ヘッダー」、つまり販売先、販売時に請求書番号（該当する場合）などと「ラインアイテム」、つまり20 * product_x @ $ 5 = $ 100を使用します。最も安全な方法は、商品テーブルの価格などに依存しないようにすることです。これらはおそらく時間とともに変化し、代わりに製品情報の大部分（すべてではないにせよ）をラインアイテムにコピーするため、価格やアイテムの説明などでも変更すると、トランザクション情報はトランザクションが行われた時点の状態のままになります。

1
Will A

顧客ごとのトランザクションプロパティを示すフィールドが含まれたテーブルが必要だと思いますORフィールドが含まれたテーブル-日付、製品（外国）、数量-このようにして、新製品で問題はありません

0
lvil

リンク付きの複数のテーブルを試す

table_products
id
name

table_product_sales
id
product_id
quantity
price_per
transaction_time AS DATETIME

SELECT table_product_sales.*, table_product.name 
FROM table_product
JOIN table_product_sales
ON table_product_sales.product_id = table_product.id
GROUP BY DATE(transaction_time)

試したことはありませんが、そのようなものはうまくいきますか？これにより、各トランザクションを個別に保持できるため、販売ごとの平均販売数、日付ごとの合計販売数、毎日の合計販売などを照会できます。

0
csi