database - 在庫データベースの設計

Question

これは、「プログラミング」に関する質問ではなく (言語やデータベースに固有のものではありません)、設計とアーキテクチャに関する質問です。また、「X を実行する最善の方法は何か」というタイプの問題でもあります。多くの「宗教的」論争を引き起こさないことを願っています。

過去に、何らかの形でアイテムの在庫を保持するシステムを開発しました (どのアイテムとは関係ありません)。トランザクションをサポートしない言語/DB を使用しているものもあります。そのような場合、アイテムレコードのフィールドに手持ちのアイテムの数量を保存しないことにしました。代わりに、手持ちの数量は、受け取った在庫の合計 - 販売された在庫の合計で計算されます。これにより、ソフトウェアによる在庫のバラツキがほとんどなくなりました。テーブルは適切にインデックス化されており、パフォーマンスは良好です。レコード開始量がパフォーマンスに影響する場合に備えて、アーカイブプロセスがあります。

さて、数年前にこの会社で働き始め、在庫を追跡するシステムを継承しました。ただし、数量はフィールドに保存されます。エントリーが登録されると、アイテムの数量フィールドに受け取った数量が追加されます。アイテムが販売されると、数量が差し引かれます。これにより、不一致が生じました。私の意見では、これは正しいアプローチではありませんが、ここにいる以前のプログラマーはそう断言しています。

そのようなシステムを設計する正しい方法についてコンセンサスがあるかどうかを知りたいです。また、これに関するガイダンスを求めるために、印刷物またはオンラインで利用できるリソースは何か。

ありがとう

score 56 · Accepted Answer

私は現在の会社で両方のアプローチを見てきましたが、間違いなく最初の方法 (株式取引に基づいて合計を計算する) に傾いています。

どこかのフィールドに総量のみを保存している場合、どのようにしてその数に達したのかわかりません。取引履歴はなく、問題が発生する可能性があります。

私が書いた最後のシステムは、各トランザクションを正または負の数量のレコードとして保存することで在庫を追跡します。私はそれが非常にうまく機能することを発見しました。

score 19 · Accepted Answer

私は第 1 巻と第 2 巻を持っていますが、これらは過去にかなり役に立ちました。

score 9 · Accepted Answer

場合によっては、在庫システムは単にアイテムを数えるだけではありません。たとえば、会計目的で、FIFO (先入れ先出し) モデルに基づいて在庫の会計上の価値を知る必要がある場合があります。これは、「受け取った在庫の合計 - 販売された在庫の合計」という単純な式では計算できません。しかし、彼らのモデルはこれを簡単に計算できるかもしれません。これはプログラミングの問題ではないため、詳細には触れたくありませんが、彼らがそれを誓う場合、彼らが対応しなければならないすべての要件を完全に理解していない可能性があります.

score 7 · Accepted Answer

状況に応じて、どちらも有効です。次の条件が当てはまる場合は、前者が最適です。

合計するアイテムの数は比較的少ない
考慮すべき例外的なケースがほとんどまたはまったくない (返品、調整など)
在庫品目の数量はあまり必要とされない

一方、アイテム数が多く、例外的なケースがいくつかあり、頻繁にアクセスする場合は、アイテムの数量を維持する方が効率的です。

また、システムに不一致がある場合は、追跡して排除する必要があるバグがあることにも注意してください

私は両方の方法でシステムを作成しましたが、バグを無視しない限り、どちらの方法でも問題なく動作します。

score 4 · Accepted Answer

既存のシステムと、それを変更するコストとリスクを考慮することが重要です。私はあなたと同じように在庫を保存するデータベースを使用していますが、監査サイクルが含まれており、領収書と同じように調整を保存しています。うまく機能しているように見えますが、関係者全員が十分な訓練を受けており、倉庫のスタッフは新しい手順をすぐに習得できるわけではありません。

あなたの場合、データベース構造全体を変更せずにもう少し追跡を探している場合は、追跡テーブル（「トランザクション」ソリューションのようなもの）を追加してから、変更を在庫レベルに記録することをお勧めします。在庫レベルへのほとんどの変更を更新して、トランザクションレコードも残すようにするのは、それほど難しいことではありません。また、定期的なタスクを追加して、在庫レベルを数時間ごとにトランザクションテーブルにバックアップすることもできます。これにより、トランザクションを見逃した場合でも、変更がいつ発生したかを検出したり、前の状態にロールバックしたりできます。

大規模なアプリケーションがどのようにSugarCRMを実行するかを確認したい場合は、データの保存方法はわかりませんが、在庫管理モジュールがあります。

score 4 · Accepted Answer

これは実際には、合計が必要になるたびに (比較的) 高価なカウントを行うことと、何かが変更されるたびにそのカウントを行うこととの比較についての一般的なベストプラクティスの質問だと思います。合計。

トランザクションを使用できない場合は、合計が必要になるたびにライブカウントを使用します。トランザクションが利用可能な場合、同じトランザクション内で在庫の更新操作と再カウントされた合計の保存を実行しても安全です。これにより、カウントの正確さが保証されます (ただし、これが複数のユーザーで機能するかどうかはわかりません)。データベースにヒットします)。

しかし、パフォーマンスが実際に大きな問題ではない場合 (そして、最新のデータベースは行をカウントするのに十分に優れているため、これについて心配することはめったにありません)、毎回ライブカウントに固執します。

score 3 · Accepted Answer

私は最初の方法を選びます。

手持ちの数量は、受け取った在庫の合計 - 販売された在庫の合計で計算されます

正しい方法、IMO。

編集：在庫の損失/損傷もシステムに考慮したいと思いますが、それはカバーされていると確信しています.

score 2 · Accepted Answer

Django-inventoryは固定資産に特化していますが、いくつかのアイデアが得られるかもしれません。

IE: ItemTemplate (クラス) -> ItemsOnHand (インスタンス)

ItemsOnHand は、より多くの ItemTemplate にリンクできます。例プリンターとインクカートリッジが必要です。これにより、ItemOnHand ごとに再注文ポイントを設定することもできます。

各 ItemsOnHand は InventoryTransactions にリンクされているため、簡単に監査できます。数千の在庫取引から実際の手持品目を計算することを避けるために、残高と日付だけのチェックポイントが使用されます。手持ちのアイテムを計算するには、クエリを実行して最新のチェックポイントを見つけ、アイテムの追加または減算を開始して、アイテムの現在の残高を見つけます。新しいチェックポイントを定期的に定義します。

score 2 · Accepted Answer

私は以前、この問題を解決するシステムに取り組んだことがあります。理想的なソリューションは、事前計算された列であり、両方の長所を活用できると思います。合計はどこかのフィールドになるため、高価な検索はありませんが、残りのデータと同期が取れなくなることはありません (データベースは整合性を維持します)。事前計算された列をサポートする RDMS は覚えていませんが、トランザクションがない場合は、それも利用できない可能性があります。

トリガーを使用して、事前計算された列を偽造する可能性があります (非常に効果的です...欠点はありません)。ただし、おそらくトランザクションが必要になるでしょう。IMHO、この種の制御された非正規化を行っているときにデータの整合性を維持することは、トリガーの唯一の正当な使用法です。

score 1 · Accepted Answer

2つの列を使用することにはいくつかの利点がありますが、不一致については説明していません。2つの列（入力と出力）を使用すると、1つの列（現在）よりも不一致が発生しにくいことを示唆しているようです。何故ですか？

score 0 · Accepted Answer

「受け取った在庫の合計 - 販売された在庫の合計」とは、次のようなものです。

Select sum(quantity) as inventory_received from Inventory_entry
Select sum(quantity) as inventory_sold from Sales_items

それから

Qunatity_on_hand = inventory_received - inventory_sold

私がこれと最初の説明を単純化しすぎたことを覚えておいてください。数量を追跡するだけで在庫管理ができることはわかっていますが、この場合はそれが問題であり、私たちが修正したいことです。この時点で変更する理由は、まさに現在の設計によって引き起こされた問題をサポートするためのコストです。

また、これは「コーディング」の質問ではありませんが、私見が非常に重要なトピックであるアルゴリズムと設計に関連していることにも言及したいと思います。

これまでの回答に感謝します。

ネルソン・マーモル

score 0 · Accepted Answer

私たちはさまざまな問題を解決しますが、そのうちのいくつかに対する私たちのアプローチは、あなたにとって興味深いものになるかもしれません。

システムが「最善の推測」を行うことを許可し、間違っていると思われる推測についてユーザーに定期的なフィードバックを提供します。

これを在庫に適用するには、次の 3 つのフィールドを使用できます。

inventory_received
inventory_sold
estimated_on_hand

次に、次の行に沿ってプロセスを (毎日?) 実行できます。

SELECT * 
FROM   Inventory
WHERE  estimated_on_hand != inventory_received - inventory_sold

もちろん、これはユーザーがこのアラートを見て、それに対して何かを行うことに依存しています。

また、inventory_sold/received を更新するか、別のフィールド「inventory_adjustment」を追加することで、何らかの方法で在庫をリセットする機能を持つことができます。これは正または負の可能性があります。

... ほんの少しの考えです。お役に立てば幸いです。

database - 在庫データベースの設計

12 に答える 12

Related

Reference