0

特定の在庫品目の手持数量を計算する最良の方法について考えていました。テーブルは非常に大きくなり、多くのトランザクションが発生するため、すべての入荷を追加してすべての出荷と販売を差し引いて、オンデマンドで手持在庫を計算するのは現実的ではない場合があります。私が思いついたアイデアの 1 つは、定期的にチェックポイント、つまり品目と手持数量の記録を作成することです。手持数量の後続の計算はチェックポイントから開始されるため、すべてのトランザクションを合計する必要はありません。

inventory item table  
id | location | item   
1    1          234
2    1          567 

receiving table
inv item | stamp      | quantity
1          2010-08-10   200
1          2010-08-30   10
2          2010-08-30   20

shipment table 
inv item | stamp      | quantity
1          2010-08-10   40
1          2010-08-30   5
2          2010-08-30   2

sale table 
inv item | stamp      | quantity
1          2010-08-10   10
1          2010-08-15   15
1          2010-08-30   1
1          2010-08-30   1
2          2010-08-30   2

checkpoint table
inv item | stamp      | quantity
1          2010-08-11   150
1          2010-08-28   135
2          2010-08-15   15

8/30の請求書1の手持ちを計算するとこんな感じ

get most recent checkpoint(inv item 1, 8/30) returns 135 units on 8/28
on-hand = 135 + receivings - (shipments + sales) 
only rcv/shp/sales that occur between the most recent checkpoint 8/30

8/14の請求書1の手持計算はこんな感じ

get most recent checkpoint(inv item 1, 8/14) returns 150 units on 8/11
on-hand = 150 + receivings - (shipments + sales) 
only rcv/shp/sales that occur between the most recent checkpoint and 8/14

私の質問は、このアプローチはどのような問題を引き起こすのでしょうか? 手持数量をテーブルに格納する以外に、膨大なトランザクション セットを処理するためのより良い方法はありますか? 手持数量をテーブルに格納する方法は、チェックポイント方式とほぼ同じですか? トリガーまたは何らかのシグナルを介して更新された場合、エラーが発生する可能性はさらに低くなりますか?

4

2 に答える 2

0

「チェックポイント」の代わりに、ある間隔で手持在庫の値 (および必要なその他の値) を要約する要約テーブルの作成を検討します。この間隔は 1 日に 1 回にすることができ、夜間のバッチ ジョブでサマリー テーブルを作成する長時間実行プロセスを実行して、ユーザーが影響を受けないようにすることができます (ユーザーが日中にこのデータを使用していると仮定します)。

データをより頻繁に更新する必要がある場合は、同じバッチ ジョブで 1 日に複数回集計テーブルを更新できます。ただし、データが利用できなくなるのを最小限に抑えるために、実際には 2 セットのサマリー テーブルを用意することができます。1 セットはクエリでロードし (クエリは長時間実行されるため、ロードに時間がかかります)、もう 1 セットは「実際の」セットです。の報告。ただし、クエリが終了したら、最初のサマリー テーブルから 2 番目のサマリー テーブルにテーブルをロードするだけです (データをダンプしているだけなので、操作は非常に高速です)。そのため、ダウンタイムは最小限に抑えられます。全体として、プロセスは次のようになります。

  1. summary1インベントリ データを含むテーブルをロードします。これは、クエリを実行して「重労働」を行う場所です。
  2. クエリが終了したら、summary2からテーブルをロードしますsummary1。これは、ユーザーが経験する唯一のダウンタイムです。これは、ロード中であっても、影響を受けないsummary1からの報告がまだあるためです。summary2
于 2010-08-30T12:51:59.663 に答える
0

あなたが説明した全体的なアプローチは問題ないようですが、エッジケースで何が起こるかに焦点を当てたいと思うでしょう. ほんの一例として、次のシナリオで何が起こるか考えてみてください。

  1. アイテム「A」の手持数量は 1 です。
  2. 顧客は「A」を 1 単位注文します。手持ち数量が 0 になりました。 (1 マイナス 1 販売のチェックポイント)
  3. チェックポイントが決まりました。「A」の数量は現在 0 単位に固定されています。
  4. 商品「A」は何らかの理由でお客様に発送できません（お客様の支払い方法が拒否された、お客様が注文をキャンセルしたなど）。
  5. アイテム「A」を元に戻して、手持数量 1 を表示する必要があります。「販売」レコードはチェックポイントの前に記録されているため、削除しても何も起こりません。

この場合、有効な解決策がいくつかあります (チェックポイントの値を変更するか、さらに良い方法として、「元に戻す」レコードを投稿して監査証跡を作成します) が、これはこのアプローチで検討すべきことの 1 つの例にすぎません。

于 2010-08-30T12:55:03.213 に答える