我面临以下问题。
想象一下关系数据库有两个相关的表:
表用户
idUser | email | otherColumns
------ | ----------- | ------------
1 | a@gmail.com | ....
表格帐单
idBill | value | otherColumns
------ | ------| ------------
1 | 100$ | ....
通过向账单表添加外键以将每个账单与一个用户相关联来建立公共关系。尽管如此,还可以创建一个这样的中间表:
关系表帐单用户
id | idUser | idBill
------ | ------ | ------------
1 | 1 | 1
使用此表,我们可以获得相同的结果,但我认为组织更好。这个选项中的任何一个比其他选项更好吗?或者取决于具体情况?
最后,我想知道是否有任何标准来创建这些关系。
感谢。
答案 0 :(得分:3)
是的,有标准 - 或者更确切地说,有许多关于数据库设计的书籍告诉你公认的智慧。最后一个我记得读到的是“数据库设计和关系理论:普通形式和所有爵士乐”,由Christopher J. Date撰写。
您的第一个问题的答案取决于业务领域。通常用这样的伪语言来总结系统是有帮助的:
用户由合成主键标识,并具有 属性xyz。
帐单由合成主键标识,具有值,具有 一种货币,有xyz。
帐单只有一个 用户。
(或)
帐单 一个或多个 用户。
(或)
帐单只有一个 用户且该关系已 属性x,y和z。
如果帐单只有一个用户,则将“user”作为外键添加到帐单表中。没有其他信息可供捕获。
如果帐单可以有多个用户,您可以创建一个链接/加入表,每个用户/帐单组合都有一行。
我的账单只有一个用户,而且该关系还有其他一些属性 - 例如该法案的税收状况 - 您可以使用任一解决方案。就个人而言,我更喜欢创建一个连接表来表明这些属性涉及账单和用户之间的关系,而不是账单本身。但是,其他人也有其他观点。
答案 1 :(得分:1)
这是关于你的设计。假设根据我们的设计,one
用户可以拥有n
帐单,one
帐单必须属于one
用户。这意味着我们应该有1-n
的关系。将此表示为pyhisical表取决于您拥有的关系类型。对于1-n
,我们可以这样做:
表用户
idUser(PK) | email | otherColumns
------ | ------ | ------------
1 | a@gmail.com | ....
表格帐单
idBill(PK) | value | otherColumns | idUser(FK)
------ | ------ | ------------ | ------
1 | 100$ | .... | 1
2 | 10$ | .... | 1
TableUser.isUser
是PK
和Unique
。 TableBill.idUser
不属于PK
和not unique
。我更喜欢这种方式来表示1-n
因为不再需要一个表(在查询中少了join
次操作)。
或者如上所述,我们可以创建关系表来链接它们:
表用户
idUser(PK) | email | otherColumns
------ | ------ | ------------
1 | a@gmail.com | ....
表格帐单
idBill(PK) | value | otherColumns
------ | ------ | ------------
1 | 100$ | ....
2 | 10$ | ....
关系表帐单用户
idUser(FK) | idBill(FK)
------ | ------------
1 | 1
1 | 2
在关系表中,idUser
字段为not unique
因为我们应该允许复制userid
s (1-n)
。 idBill必须为unique
,因为一张帐单必须只有一个所有者。您还可以根据设计要求对identifying
之间的关系进行一些更改。
关系类型:careerride
关于设计问题(ER图):tutorialspoint
表格的ER:tutorialcup
答案 2 :(得分:0)
我的建议是不要创建另一个表格'关系表账单'来映射账单表和客户。使用效果不佳:
在“表单”中添加“iduser”列,以便您可以轻松加入billtable和customer表:
表格帐单
idBill | value | otherColumns | iduser
------ | ------ | ...... | ....
1 | 100$ | | 1