外键的命名约定

当在表（mysql）中建立关系时，我遇到了一个命名困境。外键的命名约定

例如，如果我创建一个地方项目可以由多个用户创建，并通过多个用户读取的网站，要链接的问题和用户表，我想可能需要两个表。

**project_authors** 
questionId 
userId

和

**project_bidders** 
questionId 
userId

这里的问题是这两个表的外观是相同的除外表名。可能是一个更有用的表示是

project_authors 
questionId 
authorId

和

project_bidders 
questionId 
bidderID

在这里现在的问题是的AuthorID和readerId实际上只是用户id，并且名称不反映，并有可能误导表明， authorId和bidderId是独一无二的，各有不同。

我相信我的例子有很多孔，但我一直在最近遇到这个问题很多，所以我的问题是你用什么方法？

来源

2009-09-01 zenna

请不要说“关系在表格之间“。关系数据库中的关系是表本身，而不是它们与外键之间的关系。有些人对此感到困惑，所以不要进一步混淆它们！ – 2009-09-01 14:48:11

约束名可能受到数据库施加限制的严重阻碍，例如， oracle的moronic 30字符标识符限制。 – skaffman 2009-09-01 15:27:34

这有什么错author_userID和bidder_userID？

你有人扮演角色，这总是一个困难的设计。您需要反映角色以及扮演该角色的底层对象。

来源

2009-09-01 14:36:19

我认为他们的问题在于他们长而笨重。我不会调用变量loop_array_index_integer，即使它恰好是循环中用于索引数组的整数！ – 2009-09-01 17:11:26

你不会说“loop_array_index_integer”，因为你没有一个外键的两个角色。 “loop_array_index_integer”可以毫不含糊地拼写为“i”，因为类型（整数）很明显。对于数据库定义，类型（userID）和合格角色（作者或出价者）并不明显。 – 2009-09-01 18:48:17

我会说：

 
project_users 
------------- 
questionId 
userId 
roleId

其中roleId链接到该作者，投标人等积极作用区分表 - 你可以用复合主键的选择控制用户是否可以只一个（作者或投标人）或两者。前者意味着超过questionId, userId的关键，后者是所有三个领域的关键。

附注：个人而言，我更喜欢留在一个命名方案。要么我用everyhing_with_underscores，或者我用camelCase/PascalCase，但不project_users和userId同一个数据库中。

来源

2009-09-01 14:35:39 Tomalak

好的电话，谢谢你的建议。命名问题仍然存在。例如，如果每个项目只有一个作者，那么我将它包含在项目表中。例如项目 -------- 专案编号描述用户id 是用户id真是一个正确的名称，因为它没有固有的用户id是这个项目的作者表示。 – zenna 2009-09-01 14:45:08

我会使用AuthorUserId（我更多地使用SQL Server，其中PascalCase更强大，FWIW）。无论如何，一致性是关键。 Sortablity很好，所以UserIdAuthor也是一个选项，取决于你的实践。无论如何，一个语义上有用的名字总是为我赢得一个严格的名字。 – Tomalak 2009-09-01 14:50:48

如果你只是想问一下命名问题，我会使用任何命名方案本身提供的最多文档。我个人认为这将是第一个选择。然而，只要你确定你所做的任何决定都是一致的，并且以某种方式记录下来，我认为或者可以正常工作。

但是，您是否想过制作更多表格？也许有users表，其中存储ID和其他用户信息，projects表存储项目，bidders表映射用户出价项目和authors表将用户映射到创作的项目？

来源

2009-09-01 14:37:46

对不起，也许我没有说清楚，我有一个用户和一个项目表。我写的表格只是按照您的建议执行多对多关系或投标人和作者表。 – zenna 2009-09-01 14:40:37

当我可以使用我链接到的PK字段的确切名称。不过，偶尔我可能需要两个引用在同一个表相同的ID，那么我会做：

用户用户名

订单 Customer_UserID SalesRep_UserID

你知道具体使用这样该ID以及实际的ID名称。

来源

2009-09-01 14:40:09 HLGEM

我希望尽可能保持外键名称与主键名称相同。这可以帮助您快速确定列是否是另一个表的外键，并且对于它引用哪个表没有歧义。

tblUser

用户ID（PK）

tblProjectAuthor

ProjectAuthorID（PK）
用户ID（FK到tblUser）

tblProjectBidder

ProjectBidderID（PK）
用户ID（FK到tblUser）

在您查询，您可以使用前缀你引用的表的用户ID来区分。

select author.UserID 
from tblProjectAuthor author 
left join tblUser user on user.UserID = author.UserID

这个命名方案遇到的唯一问题是当您在同一个表中多次引用外键时。一个很好的例子就是一个自我加入的表格。在这样的情况下，我唯一的建议是用一个有意义的单词或短语作为前缀，以帮助区分，同时允许您识别列是外键。

例如：

tblEmployee

雇员（PK）
ManagerEmployeeID（FK到tblEmployee）

来源

2009-09-01 15:04:41 Mayo

我喜欢在我的名字真的很描述性的，因为更多的时候那么他们就不会在某些对象上找到代码作为属性名称。所以你的情况我会

project_authors 
questionId 
authoredByUserId

和

project_bidders 
questionId 
bidByUserId

然后在代码中访问它的属性时，使得很多更有意义，就像

myProjectAuthorEntity.authoredByUserId = someUserId; 
myProjectBidderEntity.bidByUserId = someOtherUserId;

来源

2009-09-01 15:25:30 JeremyWeir

外键的命名约定

回答

相关问题