1

大規模な商業建設プロジェクトのプロジェクト管理用の発注システムのテーブルを設計しています。顧客注文を入力するとき、顧客は元の発注書を持っています。将来、顧客は注文に追加するか変更を加えることによって、元の PO に変更を加えます。これらの変更は、顧客注文の変更注文としてマーク/追跡して番号を付ける必要がありますが、元の注文は、小計 (元の見積もり/注文を保持するため) と変更なしで注文の上部にそのまま残す必要があります。関連する価格の変更として以下にリストされます。次に、元の注文と変更注文を考慮した新しい合計が下部に表示されます。

これらの変更を元の注文項目/合計とは別に追跡するようにテーブルを設計する方法について、いくつかのアイデアはありますか?

これまでのところ、Customer、Order、OrderDetail、Product などのテーブルがあります。

編集：うまくいけば明確にするために：

  • 顧客が注文する (注文テーブル: OrderID、PO#、OrderDate など)
  • 注文には 1 つから複数の項目があります (OrderDetail テーブル: LineID、Qty、Description など)。
  • 注文には、1 つから複数の注文変更を含めることができます。
  • 注文変更とは、注文に項目を追加することです。各注文変更 (1 つまたは複数の項目) を文書化する必要があります (例: 「注文変更 #1」、「注文変更 #2」など)。顧客と私のクライアントの間で簡単に参照できます。

注文が行われると、顧客が後で注文に追加したい場合、OrderDetail テーブルに追加の項目が追加されます。

したがって、私のクライアントはルックアップできる必要があります:

  • 元の注文の商品と元の注文の合計。
  • 注文に対してどのような「変更注文」が行われたか。各変更注文には独自の日付と価格が設定されています。
  • 新しい注文の合計はいくらですか

私の質問は、注文変更明細を同じテーブルまたは別のテーブルに配置することはできますか? 元の注文の一部を表示するにはどうすればよいですか? 各変更管理の一部であるアイテムを表示するにはどうすればよいですか?

別のテーブルまたは 2 つのテーブルを使用するのが最善でしょうか?

編集: 考えられる解決策
@Darklantern - あなたの考えを理解できたら教えてください。

初注文：
Order Header:
- Version = 1

Order Detail:
- Version = 1 Part = A
- Version = 1 Part = B

注文変更後の注文：
Order Header:
- Version = 2

Order Detail:
- Version = 1 Part = A
- Version = 1 Part = B
- Version = 2 Part = A
- Version = 2 Part = B
- Version = 2 Part = C

これは素晴らしいことですが、元の注文の一部にすぎなかったもの、バージョン 1 の一部にすぎなかったものなどを追跡するには、あなたのアイデアは良さそうですが、「バージョン 2 パート B」が編集されたかどうかを比較せずに明確に示すことはできません。それを「バージョン 1 パート B」にします。

私はあなたのアイデアをさらに一歩進めました。それは機能しますか、または私が見ていない欠陥は何ですか:

初注文：
Order Header:
- Date, etc

Order Detail:
- Version = 0 Part = A
- Version = 0 Part = B

複数の注文変更後の注文:
Order Header:
- Date, etc

Order Detail:
- Version = 0 Part = A
- Version = 0 Part = B
- Version = 1 Part = C
- Version = 1 Part = B Upgraded to D (price is the difference between B and D
- Version = 2 Part = A removed (price is a negative amount)

その場合の懸念は、レポートがどれほど簡単になるかということです。注文書または請求書を印刷するとき、各「バージョン」を独自のグループ ヘッダーと小計とともにリストできますか? 多くの場合、各「バージョン」には独自のロット価格があるためです。

私は正しい道を進んでいますか、それともうさぎの道から外れていますか?

4

3 に答える 3

0

あなたの質問は広すぎて、あなたが達成したいことを正確に指定したいかもしれません。たとえば、変更されたアイテムに新しい行を入力してから最新の行バージョンを要求しますか、それともアイテムに1行だけを入力し（必要に応じてこの行を変更します）、変更情報を監査テーブルに入れますか（フロントエンドコーディング）。これを設計するのに役立つ可能性のあるERDをWebで探してください。この概念は、新しいものではないと確信しています。Northwind/Pubsのサンプルデータベースでいくつかのアイデアを調べてください。

于 2012-08-15T02:47:45.013 に答える
0

あなたの最初の例はまさに私が考えていたものでした。2 番目のサンプルは良いバリエーションですが、報告するのはより複雑です。お客様は、すべての変更を含め、請求書/注文のすべてを確認していますか? それとも、管理レポートツールである管理用にこれをグループ化していますか? バージョンごとに請求書のモックを作成する必要がありますか、それとも注文全体を元帳スタイルの形式で示したいですか。レポートの観点から考えると（レポートに使用されているツールはわかりません）、最初の「バージョン」はより単純であり、注文の詳細/製品ごとにリストして、すばやく比較できるようにすることができます. 各バージョンの小計を作成できます。バージョンごとにグループ化された請求書/レポートを作成することはできますが、各グループに異なるバージョンのアイテムをどのように混在させるかは、スクリプトが複雑になる可能性があります。これについてもっと考えてみます。確かに、スクリプト作成に慣れている場合は、バージョン 2 の方が優れているかもしれません。

于 2012-08-18T06:49:42.133 に答える
0

うーん...新しいメガネを買わなきゃ。私がお勧めするのは、項目を 1 つのテーブルに残すことです。Order および Line アイテムに VersionNumber を追加します。アイテムが置き換えられると、すべてのアイテム (新規を含む) が新しいバージョンにインクリメントされます (置き換えられたアイテムは元のバージョンのままになります)。最終的な注文には、ヘッダー バージョン = 一致する品目バージョンが含まれます。こちらの方が報告しやすいです。

(Ident,Orderid,VersionNumber) を使用して tblOrderVersion を使用することで、これを正規化できます。行は現在のバージョン番号で更新されます。これにより、注文のすべての反復を追跡できます。テーブルが大きくなりすぎた場合、必要なレポートを取得するために結合できる別のテーブルに冗長データを削除するのは簡単です。少しでもお役に立てば幸いです。また、説明なしに誰かに反対票を投じるのは失礼だと思います。（ところで、私はあなたに反対票を投じます）。

于 2012-08-17T00:16:44.630 に答える