必要なテーブルを把握しようとしている顧客データを保存する必要のあるデータベースがあります。これまでのところ、私は次のようなことを考えていました。
顧客テーブル：
アドレステーブル：
サイトテーブル（作業が必要な物理サイト）
顧客には、1つの連絡先アドレスと1つ以上のサイトアドレスがあります。2つの住所は同じである可能性があります（顧客が会社の住所を連絡先として使用している場合）。ただし、連絡先アドレスがサイトアドレスと異なる場合があります。
2つのアドレステーブルが必要ですか？1つは顧客の住所用で、もう1つはサイト用ですか？また、顧客ごとに2つ保管することもあるので、電話は別のテーブルにする必要がありますか？
あなたのデザインはかなり良く見えますが、おそらくアドレスとサイトにIDが必要です。顧客が持つことができる番号の数を制限しない限り、顧客テーブルに電話が必要かどうかはわかりません。サイトにはアドレスが必要ですか（物理的なサイトなのかWebサイトなのかわからないので、私はただ尋ねます）？デザインに影響を与える可能性があるので、これを取り上げます。アドレスに関連付けられている唯一のエンティティがcustomerである場合、addressにcustomer_idを含めることは理にかなっています。ただし、アドレスが顧客間で共有されている場合、またはサイトテーブルで使用されている場合は、結合テーブルを作成します。
ユーザーが持つことができる電話番号の数は可変であるとあなたは言いました。その場合、現在のように2つの電話番号を持つ顧客をハードコーディングすることはありません。別の電話番号テーブルがあると、これがより柔軟になります。
電話テーブル：
CustomerテーブルとSiteテーブルがある場合は、それらの中でAddressテーブルを参照できます。
これにより、顧客とサイトに同じアドレスまたは異なるアドレスを使用できるようになります。アドレスを更新すると、顧客とサイトの両方でアドレスが更新されることに注意してください。
顧客テーブル：
サイトテーブル：
アドレステーブル：
電話番号については、テーブルはすでに2つの電話番号を処理できます。彼らは2つの素数を持っていて、それから交互になるということですか？