我想弄清楚爲我爲一所學校俱樂部製作的網站設計這些表格的最佳方式。我想設置它，以便每個用戶可以有多個電子郵件，電話號碼和地址綁定到他們的帳戶。爲此，我嘗試將所有這些內容綁定到聯繫人表，並將聯繫人ID存儲在用戶表中作爲外鍵。聯繫人ID也是電子郵件，電話號碼和地址表中的外鍵。這是一個關聯這些表的可行方式，還是應該剪掉中間人（聯繫人表）並將用戶標識存儲在電子郵件，電話號碼和地址表中？MySQL數據庫設計 - 查明表關係的麻煩
萬一我的關係的描述還不夠，這裏是表的ERD：
對不起，這樣的「小白」的問題，它已經有一段時間，因爲我有構建比2個表更復雜的數據庫。任何數據庫設計的一般技巧也非常受歡迎。
您只需要移除聯繫人表並將user_id存儲在右側的表中，而不是contact_id。
也從用戶中刪除contact_id。
除非聯繫人可以是多個用戶，否則我想。 – podiluska
是的，確切地說。如果你有一個M：N的關係，這是一個不同的故事，但你的問題假設你沒有。 – Gigi
好的，我有一個想法，這是我需要做的，但我有一個習慣，使事情比他們需要更復雜。爲了記錄，用戶和電子郵件，電話號碼和地址之間的關係是M：N。感謝您的幫助。 – KylePlusPlus
我已經在過去處理過這個問題。我們做錯了，我們很抱歉。
的決定因素應該是這些：
你將有一個人任何其他類別的不是用戶，對他們來說，你需要存儲聯繫人信息？
這些類型的人會以某種方式與用戶「可互換」嗎？
如果你回答都這些問題「是」，您的聯絡表。否則擺脫它。
我工作的一個團隊犯的錯誤是我們對第二個問題的回答。我們有醫療病人和醫生/護士等作爲我們的人員類別。我們一起存儲他們的聯繫信息。但我們不應該那樣做，因爲患者的聯繫信息非常敏感和保密，但醫療保健提供者的信息卻少得多。我們一直希望在系統成功後，我們在一組表中沒有這兩種數據。
除非你能說服自己，否則你需要你的聯繫表，擺脫它，我說！
我不認爲我會遇到任何問題，因爲每個用戶都有一個「地位」來決定他們在俱樂部中的角色（例如會員，總裁，司庫等）。我選擇擺脫聯繫表，就像你所建議的那樣。感謝您的幫助。 – KylePlusPlus
這是一個很好的觀點。人與聯繫人。 （苦）經驗告訴我這裏概述的方法的價值。 –
據我可以設計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持有約contacttype即電子郵件，家庭電話，移動電話，家庭地址，送貨地址等 信息表2保存關於用戶，聯繫人類型和其值的信息 就像cinatacttypeid對應於移動的值比較等。
這是一個有趣的方法來存儲數據。 ContactType成爲任何類型聯繫信息的通用容器。但是，我看到的主要問題是，如果聯繫類型具有多個字段，如地址。 – KylePlusPlus
Contact.Type.Description可以是一個地址嗎？沒有驗證或格式化，除非我們有單獨的字段......我們不需要電子郵件地址。 –
你打敗了我;） –
是的，我會切出的midle人：
雖然我很想去「CONTACT_TYPE」的路線，我發現，通常有驗證並變得更加複雜不同的數據類型時的接觸是通用。例如，具有地址字段的表與電話號碼不同，並且兩者呈現出更多的複雜性和更少的可讀性。
該模型着重於簡單性，例如，用戶有很多電子郵件，並且電子郵件屬於用戶。
最好的辦法是使用表繼承並使其類AbstractAddress的所有亞型。然後您可以輕鬆地查詢用戶所有地址。這就是Hay，Silverston，Fowler和其他人所推薦的。 –
表繼承是Fowler（這裏http://www.martinfowler.com/eaaCatalog/singleTableInheritance.html）討論的軟件設計模式，它與RDBMS模式設計問題並不真正相關 - 而且是一個好的一個在那。 –