データベース設計に関するコメント/提案 - 倉庫在庫管理

Question

データベース設計に関するコメント/提案 - 倉庫在庫管理

私は現在、複数の倉庫を使用する在庫管理システムを作成しています（サブロケーションを含む）。これが私の最初の大きなプロジェクトですから、いくつかのフィードバックが大好きです。

Let me show you what I have done so far... Link as Im still new here

最初に倉庫を作成し、その倉庫内に場所を作成する必要があります。

ItemType（ItemGroup）を作成して、そのグループのItemを作成することもできます。

在庫を追加することができるアイテムとロケーションがあれば、ストックテーブルにはコンポジットキーがあるので、重複を追加することはできません。私はまたあなたが誤ったItemTypeのItemを入力することができないように制約を追加しました.Warehouse/Locationに同じ制約があります。

私は、在庫、SerialisedItemsとNonSerialisedItemsの各部分のレコードを保持する必要があります。例：シリアル化されていない在庫が数量10で追加された場合、現在、関連する在庫情報とともに在庫ありに設定されているNonSerialisedItemsテーブル（1）内に10行が作成されます。彼らが株式の量を変更すると、行が削除または追加されます（2）。

Warehouseと似ているVanテーブルを使うこともできますが、WarehouseテーブルをWarehouseとVanの2つのテーブルを参照するStorageに変更する必要があると思いますか？

(1) I currently have a TransactionScope on my page adding x number of rows, Is this the best way to handle that? (2) The Quantity amount in the Stock table would have to count the number of rows for that item and then update the Quantity each time stock is added or removed, any problems here? - Both Questions Fixed - Only create rows for serialised items.

その他の問題はありますか？

それは良いか恐ろしい私が知っている場合、まあそれは私がやったことです。また、落とし穴がある場合は、それを知っていると嬉しいこともあります。

ありがとう

[EDIT] ありがとう to Neville K I have made a few changes...

新しい改良されたデータベースへのリンク

これはもっと意味があるようです！私はそれを昨日ずっと見つめていたと思うよ！

1

追加された 06 2月 2012 〜で 11:20 著者 Luckyl337 編集された 07 2月 2012 〜で 02:39

ビュー: 3

源

ru fr es pt de ar

（2）は間違いです。大量個のアイテムがある可能性があります。小さなネジ。さらに悪いことに、数量が分数（310.25m）になるケーブルのようなアイテムがあるかもしれません。

追加された 06 2月 2012 〜で 11:35, 著者 Erich Kitzmueller, 源

ケーブルは1/4mのように分数で販売することもできます。もちろんcmやmmごとに行を作成することもできますが、意味がありません。私はいくつかの倉庫管理システムを作成しましたが、シリアル番号などを追跡する必要がなければ、在庫の各行を作成する必要はありませんでした。

追加された 06 2月 2012 〜で 11:56, 著者 Erich Kitzmueller, 源

ピックバッチの在庫数量を即座に差し引くのは、IMOではありません。在庫品目テーブルに2つの列があります.1つは利用可能在庫（これはピッキング一覧が作成されると即座に控除されます）と1つが実際の在庫（ピッキング直後に差し引かれます）です。実際の（物理的な）在庫状況を把握することは、倉庫管理における重要な側面です。

追加された 06 2月 2012 〜で 12:46, 著者 Erich Kitzmueller, 源

大量には、私が心配していたものです、私はちょうど必要に応じてそれらを作成することができますね？私はケーブルの考えを持っていなかったので、ケーブルがメートル単位で販売されたら、個々のアイテムとして各メーターを保管することができますので、まだ動作するか、安く感じますか？

追加された 06 2月 2012 〜で 11:51, 著者 Luckyl337, 源

シリアライズされたアイテムはユニークなシリアルを持ち、追跡されますが、それは私にとっても意味がありますが、顧客は、「販売時の価値」、「レシート番号」のシリアル化されていない各アイテムを追跡したいと考えています。私はまた、倉庫間を移動するためにアイテムを「Pick Batch」に置くことができる必要があります。しかし、ちょうど今私はあなたが私に気づかされたと思う...私は販売/購買情報をとにかく記録するだろう、なぜ私は各項目、笑にこの情報を記録する必要がありますか？一時的な「Pick Batch」に関しては、在庫数量を差し引いて、アイテムが移動されるまでPickBatchテーブルにアイテムを配置しますか？ありがとう！

追加された 06 2月 2012 〜で 12:40, 著者 Luckyl337, 源

1 答え

著者 Neville Kuyt · Answer 1 · 2012-02-07T01:14Z

まず、これはかなり解決された問題です。私が知っている最高のリソースは、 "データモデルのリソースブック"シリーズ;そこには在庫管理アプリケーション用の非常に柔軟なモデルがあります。

第二に、あなたのデザインはあまり正規化されておらず、多くの重複に依存しています。推論が何であるかはわかりませんが、通常、「在庫」テーブルには「アイテム」へのリンクがありますが、「アイテムタイプ」にはリンクされません。アイテムがアイテムタイプに属するという事実は、アイテムとアイテムの関係あなたはそれを複製する必要はありません。場所と倉庫についても同じことが言えます。

私が示唆している重要な変更は、単一の「在庫」テーブルではなく、株式取引の概念です。

行に沿った何か

TransactionID      date    itemID  locationID  quantity 
------------------------------------------------------------------
1                1/1/12        1            1       10
2                1/2/12        1            1       -1
3                1/3/12        1            1       20

ある品目の現在の在庫を調べるには、（品目別に）品目を合計します。項目別の現在の在庫を場所別に検索するには、項目、場所ごとに合計（数量）します。

1月1日には、10項目の在庫がありました。 2番目の項目では、1件の項目が削除され、9件の在庫が残りました。 3番目に20の新しいアイテムが入荷し、残りの29アイテムが入荷しました。

この設計により、一般的な要件である経時変化を追跡することができます。トランザクションメタデータ（operatorID、請求書番号など）を作成して監査証跡を提供します。