請求書と注文のモデリング
注文と請求書を含むデータベースのモデリングに問題があります。実際には、ビジネスの観点から見ると問題ですが、それでもデータベースのモデル化に関連しています。
Ordersテーブルのモデル：
今私はpayment_deadlineと呼ばれる別の列を持っていました、それはよく支払い期限がありました。私が考えているのは、Ordersテーブルに必要な情報と、Invoicesテーブルに必要な情報は何ですか？
どちらに従業員IDと顧客IDがありますか？価格はどれですか？どちらに支払い情報がありますか？どちらに期限情報がありますか？私は完全に迷っています。
ビジネスの世界では、注文は商品のプロバイダーが行動する必要があることを示し、請求書は商品プロバイダーが彼の役割を果たし、顧客が商品/サービスの料金を支払う必要があることを示します。しかし、データベースでそれをどのようにモデル化するかについて迷っています。どんな洞察も大歓迎です。
あなたの質問はmuchで、特定のテーブル設計の提案を提供するには広すぎます。 「これは従業員がいる」ということは、ニール・マクギガンによる The Answer で言及されているように、何十ものことのいずれかを意味する可能性があります。最初に顧客の問い合わせ電話を取った人、応答した営業担当者セールスオーダーに記入したセールスアシスタント、セールスオーダーの受領を確認した生産マネージャー、作業オーダーでアイテムを生産した作業員など。
しかし、私はあなたがあなたが要求した洞察のいくつかを提供するかもしれない簡単な概要をあなたに与えます。
取引トランザクションのライフサイクル
Wikipediaの定義を使用して、ベンダー顧客の通常のワークフローをこの図に示します。色の意味：
- ピンク色のアイテム=顧客ベンダーと連絡先/ドキュメントなしのやり取り
- 青色の項目=顧客との間のドキュメント
- 黄色のアイテム=ベンダー内部のドキュメント。
営業担当者と相談した後（オプション）、顧客は Purchase Order をベンダーに送信し、購入を決定したサービス/製品を正確に説明します。ベンダーに受け入れられると、法的拘束力のある 契約 が確立されます。
Sales Order は、ベンダーの営業担当者が作成し、購入注文の内容を反映しますが、ベンダーの内部スタッフにとって意味のある形式と専門用語を使用します。
ベンダーの内部スタッフ、生産関連のマネージャー（上級職人、製造マネージャー、倉庫管理者など）が1つ以上の Work Order を作成して、サービス/製品をレンダリングするために何をすべきかをスタッフに指示します顧客が望む。
購入アイテムの一部または全部が顧客に提供されると、ベンダーによって Invoice が作成され、支払いを要求するために顧客に配送されます。請求書は注文番号/ IDを参照する必要があります。
最後に、顧客はある種の 送金通知 請求書番号/ IDを参照して支払いを行います。この手順により、トランザクションが完了します（返品、 変更要求 、またはその他の問題は無視されます）。
上の図は、テーブルではないテーブルまたは エンティティ図 です。たとえば、1つの販売注文に対して複数の作業注文があるとします。顧客への部分的な配達が行われた場合、複数の請求書が作成されることがあります。または、製造スタッフが一度に2つのユニットWonderWidgetのみを構築して無駄を回避するとします。そのため、別の顧客が2つ目のウィジェットを注文するのを待つ必要がありますが、待っている間はまだWork Orderを作成していません。その間、受注の他の品目から開始することができ、これらの初期品目の作業指示書を作成します。このシナリオには、多対多の関係があり、どの販売注文にも複数の作業注文を含めることができます（お客様は、WonderWidget生産開始）各ワークオーダーに複数のセールスオーダー（ダブルの場合は異なる顧客からの1対のセールスオーダー-WonderWidget生産）。
対面小売
対面型の小売りははるかに単純で、ワークフローは3つの瞬間的なステップからなり、そのうち2つだけがドキュメント（またはデータベースエンティティ）になります。
顧客は店の棚からいくつかのものをつかみ、チェックアウトカウンターに提示し、レジスターがアイテムを集計し（注文のように）、支払いが実行され、レシートが作成されます。販売領収書は、基本的には、レジスターの集計（販売注文）と支払いの詳細（クレジットカード番号の一部、日時など）を組み合わせたものです。
繰り返しになりますが、返品などの問題を無視しているため、これは単純化されています。
繰り返しますが、この図はテーブルやエンティティの図ではありません。
Web /電話小売
オンラインのWebまたは電話での注文では、ワークフローはおそらく上記の2つの組み合わせになります。お客様がすぐに支払う場合、請求書および送金通知書は必要ありません。小さな店の場合、販売注文と作業注文は同じ単一のエンティティである可能性がありますが、これが複数の倉庫を持つAmazon.comスタイルのビジネスの場合は、複数の作業注文があります。
簡略化しすぎた部分テーブル図
テーブルデザインの初心者としてあなたに味を与えるために、これは非常に単純化されたデザインです。受注のための部分的なデザイン。この図では、単純な crows-foot表記 および Postgresデータ型 を使用しています。省略形：pkは 主キー を意味し、fkは 外部キー を意味します。
価格は注文表に記載しないでください。販売注文には多くのラインアイテムがあります。価格はラインアイテムに属しています。配達日もそうです。
請求書は、支払いの要求です。注文には多くの（またはまったくない）請求書を含めることができ、請求書は多くの注文に対応できます。それは多対多の関係です。
配達前に支払う場合（またはサブスクリプションサービスを行わない場合）、実際には請求書は必要ありません。
こちらのリファレンスをご覧ください すぐに使えるデータベースモデルの例 。シルバーストンはモデルをよく注文します。
注文には複数の従業員が関与する可能性があります：委託販売担当者、注文担当者など。また、複数の顧客：注文者、実際に製品/サービスを使用する人、注文の支払い者、発送先のパーティー。
たとえば、おばあちゃんはリトルスージーを注文するために電話をかけることができます。おじいちゃんが支払います。注文はママに送信されます。