我正在试图找出为我正在为学校俱乐部制作的网站设计这些表的最佳方法。我想设置它,以便每个用户可以拥有多个与其帐户绑定的电子邮件,电话号码和地址。为此,我尝试将所有这些内容绑定到联系人表,并将联系人ID作为外键存储在users表中。联系人ID也是电子邮件,电话号码和地址表中的外键。这是关联这些表的可行方法,还是我应该删除中间人(联系人表)并将用户ID存储在电子邮件,电话号码和地址表中?
如果我对关系的描述不够,这里有一个ERD表:
很抱歉这样一个“noob”问题,因为我必须构建一个比2个表更复杂的数据库,所以已经有一段时间了。任何有关数据库设计的一般提示也非常受欢迎。
答案 0 :(得分:3)
您需要做的就是删除Contacts表并将user_id存储在右侧的表中,而不是contact_id。
也可以从用户中删除contact_id。
答案 1 :(得分:3)
我过去曾处理过这个问题。我们做错了,我们很抱歉。
决定因素应该是:
您是否还有其他类别的用户,您需要为其存储联系信息?
这些人会以某种方式与用户“互换”吗?
如果您回答这两个这些问题“是”,请保留您的联系表。否则摆脱它。
我工作的团队所犯的错误是我们对第二个问题的回答。我们有医疗患者和医生/护士/等等。我们将其联系信息存储在一起。但我们不应该这样做,因为患者的联系信息非常敏感和保密,但医疗服务提供者的信息却不那么严重。我们一直希望在系统成功后我们在一组表中没有这两种数据。
除非你能说服自己需要你的联系表,否则我要说清楚它!
答案 2 :(得分:2)
是的,我会切掉那个中间人:
虽然我很想去'contact_type'路线,但我发现通常有验证和不同的数据类型,当联系人是通用的时候会变得更复杂。例如,具有地址字段的表与电话号码不同,并且两者都表现出更多的复杂性和更低的可读性。
该模型侧重于简单性,例如用户有很多电子邮件,电子邮件属于用户。
答案 3 :(得分: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包含有关联系类型的信息,即电子邮件,家庭电话,移动电话,家庭住址,送货地址等 表2包含有关用户,联系类型及其值的信息 比如cinatacttypeid对应于移动而不是值等等。