外键的命名约定

Question

当在表之间建立关系时（在mysql中），我遇到了一个命名困境。

例如，如果我创建的网站可以由多个用户创建项目并且也可以由多个用户阅读，那么为了链接问题和用户表，我可能需要两个表。

**project_authors**
questionId
userId

和

**project_bidders**
questionId
userId

这里的问题是两个表看起来完全相同，不包括表名。可能是一个更有用的表示

project_authors
questionId
authorId

和

project_bidders
questionId
bidderID

现在的问题是authorId和readerId实际上只是userIds，并且名称没有反映出来，并且可能误导性地表明authorId和bidderId本身就是唯一且不同的。

我相信我的例子会有很多漏洞，但我最近遇到过这个问题，所以我的问题是你用什么方法？

Answer 1

author_userID和bidder_userID出了什么问题？

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

Answer 2

我会说：

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

其中roleId链接到区分作者，投标人等的表。正面效果 - 您可以通过选择复合主键来控制用户是否只能是一个（作者或< / em> bidder）或两者兼而有之。前者意味着超过questionId, userId的关键，后者是所有三个领域的关键。

旁注：就个人而言，我更喜欢坚持一个命名方案。要么我使用everyhing_with_underscores，要么使用camelCase / PascalCase，而不是project_users和userId在同一个数据库中。

Answer 3

当我可以使用我链接的PK字段的确切名称时。但是，偶尔我可能需要在同一个表中对同一个id进行两次引用，然后我会这样做：

用户 用户ID

订单 Customer_UserID SalesRep_UserID

通过这种方式，您可以了解ID的具体用法以及实际的ID名称。

Answer 4

如果您只是询问命名，我会使用任何命名方案提供最本身的文档。我个人认为这将是第一选择。但是，只要你确定你所决定的内容是否一致并以某种方式记录，我认为其中任何一种都可以正常工作。

但是，你想过制作更多桌子吗？也许有一个users表，用于存储ID和其他用户信息，一个用于存储项目的projects表，一个bidders表，用于映射出价到项目的用户，以及authors表将用户映射到创作的项目？

Answer 5

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

tblUser

• UserID（pk）

tblProjectAuthor

• ProjectAuthorID（pk）
• UserID（fk to tblUser）

tblProjectBidder

• ProjectBidderID（pk）
• UserID（fk to tblUser）

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

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

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

例如：

tblEmployee

• EmployeeID（pk）
• ManagerEmployeeID（fk to tblEmployee）

Answer 6

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

project_authors
questionId
authoredByUserId

和

project_bidders
questionId
bidByUserId

然后在代码中，访问属性时更有意义，比如

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