私は単純なeコマースタイプのサイトを用意しています。これらのサイトには、ユーザーのアカウント、注文、連絡先/請求情報が記載されています。効率と論理的な観点からこれらのテーブルを設定する最良の方法を知りたかっただけです。これまでは基本的に2つの異なるエンティティ、ユーザーと注文があります。ユーザーには名前やパスワードなどの基本的なアカウント情報があり、注文には特定の注文に関するすべての情報が含まれます。データベースの設計、テーブルの設定方法
私の質問は、すべての連絡先/請求情報をユーザーテーブルに含めるか、連絡先情報と請求情報を含む2つのテーブルを作成する必要がありますか？
あなたはこのもう少し考えるする必要がある場合があります：
ユーザーが連絡先と請求先住所を持って、どのような出荷や他のアドレスについてはどうですか？ 1つの会社の2人のユーザーを持つことは可能ですか？連絡先は異なりますが、請求先住所は同じですか？ 1人のユーザーが注文時に選択する複数の請求先住所を持つことは可能ですか？
お客様のご注文については、お客様が請求先住所を更新した後、請求先住所が変更される前に注文を引き上げるとどうなりますか？古い注文の請求先住所は新しい注文か、注文時の請求先住所ですか？
説明した問題が簡単で、ユーザーが連絡先と請求先のアドレスを持っていて、他の「what ifs」がない場合は、それらのアドレスをユーザーの表に入れるだけです。しかし、私の限られた経験から、このアドレスは、特定のユーザーとは別に、独自の権利を持つエンティティである必要があることがわかります。実際、「ユーザー」を「連絡先アドレス」と考えることがあります。
連絡先情報がユーザーテーブルにある必要があると思うので、専用の郵便番号表などに正規化する必要はありません。支払い情報と同じで、クレジットカード番号などのようなものです。請求情報が特定のプランを意味する場合、別の利用可能なプランを別個のテーブルに入れ、それを外部キーでリンクします。
との請求情報が同時に表示されても、そのうちの1つを使用することはほとんどありません。いずれにしても、それらを別のテーブルに分けることはほとんどありません。
一方、多くの場合、連絡先または請求のいずれかを検索するだけであれば、分離によってパフォーマンスが向上する可能性があります。
私は個人的には、私はそれらの両方を望んでいない何回も予見できないので、個人的には分離しません。
連絡先、請求、出荷（必要な場合）の情報は論理的には別です。純粋な正規化の観点からは、アドレスは別のエンティティである必要があり、CustomersとAddressの間に関係がある必要があります。正規化の観点から最も正しいアプローチは、顧客と住所の間に多対多の関係を持ち、請求、連絡先、配送先住所を区別するためのタイプ（それぞれが1つ以上あることを前提としています） 。
あなたの製品も考慮する必要があります。一般的なアプローチは、その下にLinesテーブルを持つOrderテーブルを持つことです（OrderからLinesへの1対多の関係）。各ラインは、数量、価格およびその他の関連情報（割引など）を含む単一の商品を参照します。シンプルな価格設定は、商品表の価格入力で調整することができます。より複雑な価格設定戦略は明らかにもっと多くの努力を必要とするでしょう。
誰もが私が遠すぎると言う前に、「シンプルな」サイトはしばしば進化しています。データモデルを事前に取得することで、未知の苦労を省くことができます。
「ユーザー」が複数の連絡先を持つ場合がありますか？
"顧客"が複数の連絡先を持つことができるデータベース設計がありました。そのような場合、連絡先のテーブルを個別に管理する必要があります。そうでなければ、他の人が言ったように、あなたはいつもそれらを一緒に照会するので、同じテーブルにユーザーとその連絡先情報を保存することができます。
確かに宿題のようです。 –
これはそうかもしれませんが、これは私が完全にERDを無料で行っているとは限りません。物事を設定する方法に関するアドバイスは公正な質問のようです。 –
それは仕事のためのプロジェクトですが、私はデータベースデザインに少し錆びているので、必要な一般的なアドバイスもあります。 – roflwaffle