0
私は顧客の住所を保管し、在庫システムの注文に関連付けるデータベース設計に苦労しています。 あるAddressId
顧客と注文の住所情報の保存
お客様
得意
CustomerNameの.....
CustomerAddress
得意
AddressTypeに（課金、送料など：現在、私は次のスキーマのアイデアと3つのオプションを持っています）
住所1
住所Lin e2の 市
州
国 郵便番号
受注（オプション1）
は受注
得意
BillingAddressID
受注（オプション2）
をShippingAddressID 210受注
得意
BillingAddressLine1
BillingAddressLine2
BillingCity
BillingState
BillingCountry
BillingPostCode
ShippingAddressLine1
ShippingAddressLine2
ShippingCity
ShippingState
ShippingCountry
市ppingPostCode
受注（オプション3）
受注
得意
BillingAddressBlob
ShippingAddressBlob
私は、静的な残業を維持するためのアドレスを必要とします。 2年前に注文を振り返ってみると、正しい住所項目も出荷され、請求されていることがわかります。
満たし
希望を確認することができます順序が出荷された正確なアドレスを確認するには、顧客のために
を存在していたどのように多くの異なるアドレスを参照することができます私はすでにそのウェブサイトとリンクしているshemasを見てきました。残念ながら、それらのスキーマ内の注文と住所の間にはリンクがないので、彼らは助けません。 – Kiwi
ありがとうSiva、orderaddressのために別々のテーブルを作成する理由を説明できますか？オーダーごとに1つの配送先住所と1つの請求先住所があるだけなので、注文表に2つのアドレスIDを持たないのはなぜですか（オプション1）？ – Kiwi
- Order to Addressは1〜1のマッピングであり、Customer to Addressは1対多のマッピングになります。 1つ以上のアドレスが存在する可能性がありますが、アクティブなアドレスのみが存在する必要があります。 OrderがNew Addressエントリで更新されると、OrderAddressテーブルで更新されます。むしろCustomerAddressテーブルに新しいエントリが追加されます。また、レコードを照会するときに、顧客の注文数を検索する場合もあります。詳細が必要な場合を除き、顧客に関連付けられた住所は必要ない場合があります。これはクエリの使用法に基づいています（私の見解） – Siva