5

こんにちは私は請求書発行アプリケーションを開発しています。

したがって、一般的な考え方は2つのテーブルを持つことです。

Invoice (ID, Date, CustomerAddress, CustomerState, CustomerCountry, VAT, Total);

InvoiceLine (Invoice_ID, ID, Concept, Units, PricePerUnit, Total);

ご覧のとおり、この基本的な設計は、クライアントが同じアドレス、州、国を持つレコードの多くの繰り返しにつながります。

したがって、別の方法は、アドレステーブルを作成してから、アドレス<-請求書の関係を作成することです。

ただし、請求書は不変の文書であり、最初に作成されたとおりに保存する必要があると思います。顧客が住所や州を変更することがあります。住所カタログからのものである場合は、以前に作成されたすべての請求書が変更されます。

それで、あなたの経験は何ですか？

顧客の住所は請求書にどのように保存されますか？請求書テーブルにありますか？アドレステーブル？または、他の何か？

これについてさらに詳しく説明されている本、記事、またはドキュメントへのポインタを提供できますか？

4

3 に答える 3

8

そのような顧客の詳細を請求書に保存しないことを強くお勧めします。

代わりに、次のような構造になります。

IDの主キーを持つ顧客テーブル

顧客IDを外部キーとして使用した顧客アドレステーブル（各顧客は時間の経過とともに異なるアドレスを持つ可能性があるため）

顧客アドレステーブルへの外部キーであるアドレスフィールドを含む請求書テーブル。

ところで、広告申込情報ごとにVATフィールドを追加することを検討します。アイテムの種類ごとにVAT率が異なる国があります。

于 2010-06-02T00:23:55.797 に答える
2

ほとんどの標準的な製品/注文データベースには

a products table (ProductId, product info fields)  
a customers table (CustomerID, customer info like address etc) 
and an orders table  (OrderNumber, CustomerID, date, etc)

次に、注文アイテムは、注文と製品の間の多数の関係テーブルになります。

orderItems (OrderNumber, ProductID, quantity, purchasePrice, vat, etc)

完全な請求書を取得するには、ordersテーブルにクエリを実行し、OrderItemsテーブルと結合します。OrderItemには通常、購入価格などがあります。これは、注文の作成後に商品テーブルの価格が変更される可能性があり、その情報を保存するのに役立つことが多いためです。

于 2010-06-02T00:31:03.717 に答える
0

、、の3つのテーブルを使用して実行することを検討しますがCustomer、アドレスが入力されるInvoiceとAddress、アドレスが更新または削除されることはなく、非推奨になるように構成します。IsDeprecatedアドレステーブルにorまたはIsActivebooleanフィールドを含めることができます。次に、請求書を作成すると、請求書はCustomerIDとその時点で使用されているAddressIDにリンクします。顧客が住所を変更すると、新しいAddressIDを使用して新しいレコードを作成し、ブールフィールドを使用して古いレコードを非推奨にします。または、本当に良い記録を保持したい場合や、このデータを検索する必要がある場合は、AddressActiveStartDateとを使用できますがAddressActiveEndDate、これによりクエリが少し複雑になります。

そうすれば、古い住所を保存し、参照用に顧客にリンクしたまま、顧客が複数の住所（たとえば、配送用、請求用）を持つことができます。

必要に応じて、、、などのテーブルを追加ProductできInvoiceLineますState。

于 2014-08-06T07:17:49.690 に答える