1

このデータベースは顧客データベースを追跡するために設計されていますが、少し複雑な設計だと思います。もっと簡単にできると思います。誰か設計についてアドバイスをいただけますか? ここに画像の説明を入力

ここに画像の説明を入力

4

3 に答える 3

0

もう1つの部分的な解決策は、連絡先のテーブルを使用することです。顧客には連絡先があります（1対多）。各連絡先には複数の電話番号が含まれている場合がありますが（その場合でも、必要な携帯電話番号は1つ、自宅番号は1つ、職場番号は1つ、FAX番号は1つだけです）、電子メールアドレスは1つだけです。

于 2012-10-04T09:29:51.347 に答える
0

ここで単純さが重要なポイントである場合は、次のように、顧客関連の住所タイプ情報を 1 つのテーブルに折りたたむことをお勧めします。

    customer_contact_details{
    customer_id MEDIUM_INT
    contact_type VARCHAR2(10)
    contact_details VARCHAR2(100)
    status BOOLEAN
    }

contact_type フィールドは、必要にHome Phone,email,primary_email,work_phone,primary contact応じてタグ付けできます。その後、関連するすべての連絡先情報を 1 つのテーブルにまとめることができます。スキーマを合理化し、情報を理解するために必要な結合は 1 つだけです。

于 2012-10-04T09:02:26.260 に答える
0

この図に関するいくつかの考え:

  • 多対多の結合テーブルに主キーを設定します (おそらく、両方の列が PK である必要があります)。
  • 表内の「重複した」電話番号は、正規化のルールに違反しているとは思いません。むしろ、偶然だと思います。たとえば、2 人の人物の名前が「Joe」であるという理由だけで、名のテーブル全体が存在するわけではありません。また、2 人が同じ電話番号を共有している場合、そのうちの 1 人が別の番号を取得するとします。phone直接参照する場合、1 つの数値を更新するのは簡単な操作ですが、同じことを行うためだけにCustomer新しい数値を挿入し、結合テーブルに複数の操作を行うのは (私にとっては) 奇妙です。phone
  • と同じ取引Email。
  • 複数の選択肢がある場合、アプリはどの電話またはメールを使用するかをどのように選択しますか? defaultビットまたはordinalコラムを提供する必要がありますか?
  • 顧客は多くの場所、多くの会社、またはその両方を持っていますか?
于 2012-10-03T15:34:47.673 に答える