3

私は学校のクラブのために作っているウェブサイトのためにこれらのテーブルをデザインするための最良の方法を見つけようとしています。各ユーザーが自分のアカウントに関連付けられた複数の電子メール、電話番号、およびアドレスを持つことができるように設定したいと思います。これを行うために、これらすべてを連絡先テーブルに関連付け、連絡先IDを外部キーとしてusersテーブルに格納しようとしました。連絡先IDは、電子メール、電話番号、およびアドレステーブルの外部キーでもあります。これは、これらのテーブルを関連付けるための実行可能な方法ですか、それとも仲介者（連絡先テーブル）を切り取って、ユーザーIDを電子メール、電話番号、およびアドレスのテーブルに保存する必要がありますか？

関係の説明が十分ではなかった場合に備えて、テーブルのERDを次に示します。

ERD

このような「noob」の質問で申し訳ありませんが、2つのテーブルよりも複雑なデータベースを構築する必要があったので、しばらく経ちました。データベース設計の一般的なヒントも大歓迎です。

4

4 に答える 4

3

必要なのは、Contactsテーブルを削除し、contact_idではなくuser_idを右側のテーブルに保存することだけです。

ユーザーからcontact_idも削除します。

于 2012-09-08T17:23:15.123 に答える
3

私は過去にこの質問に対処したことがあります。私たちはそれを間違えました、そして私たちは申し訳ありませんでした。

決定要因は次のとおりです。

  1. 連絡先情報を保存する必要がある、ユーザーではない他のカテゴリの人はいますか？

  2. そのような人はどういうわけかユーザーと「代替可能」になるのでしょうか？

これらの両方の質問に「はい」と答えた場合は、連絡先テーブルを保管してください。そうでなければそれを取り除きます。

私が取り組んだチームが犯した間違いは、2番目の質問に対する私たちの答えでした。私たちのカテゴリーには、医療患者や医師/看護師などが含まれていました。彼らの連絡先情報を一緒に保存しました。しかし、患者の連絡先情報は非常に機密性が高く機密性が高いため、そうすべきではありませんでしたが、医療提供者の情報はそれほど重要ではありません。システムが成功した後、1セットのテーブルに2種類のデータがないことを常に望んでいました。

あなたがあなたの連絡先テーブルが必要であるとあなた自身に納得させることができない限り、それを取り除いてください、と私は言います！

于 2012-09-08T17:26:16.290 に答える
2

はい、私は真ん中の男を切り取ります：

'contact_type'ルートを使用したくなりましたが、通常、検証とさまざまなデータタイプがあり、連絡先が一般的な場合はさらに複雑になることがわかりました。たとえば、アドレスフィールドを持つテーブルは電話番号と同じではなく、両方を持つと、複雑さが増し、読みやすさが低下します。

このモデルは単純さに焦点を当てています。たとえば、ユーザーには多くの電子メールがあり、電子メールはユーザーに属します。

ここに画像の説明を入力してください

于 2012-09-08T17:35:59.063 に答える
1

私によると、それに応じてDBを設計することができます

Table 1 : Users
UserID //PK
Name

Table 2 : Contacts
ContactID  //PK
UserID  //FK to Users
ContactTypeID   // FK to ContactType
Value

Table 3 : ContactType
ContactTypeID   //PK
ContactTypeName
Description

表1は、ユーザー情報を格納していることを明確に示しています。表3は、連絡先タイプ（電子メール、自宅の電話、携帯電話、自宅の住所、配送先住所など）に関する情報を保持しています。等

于 2012-09-08T17:34:37.823 に答える