主键/外键命名约定

在我们的开发小组中，我们对主键和外键的命名约定进行了激烈的辩论。我们小组基本上有两种思想流派：

1：

Primary Table (Employee)   
Primary Key is called ID

Foreign table (Event)  
Foreign key is called EmployeeID

要么

2：

Primary Table (Employee)  
Primary Key is called EmployeeID

Foreign table (Event)  
Foreign key is called EmployeeID

我不希望在任何列中重复表的名称（因此，我更喜欢上面的选项1）。从概念上讲，它与其他语言中的许多推荐做法是一致的，在这种情况下，不要在对象的属性名称中使用对象的名称。我认为命名外键EmployeeID（或Employee_ID可能更好）可以告诉读者这是表的ID列Employee。

其他一些人则更喜欢选项2，在该选项中，您将主键命名为表名，以使整个数据库中的列名相同。我明白了这一点，但是现在您无法从视觉上区分主键和外键。

另外，我认为将表名包含在列名中是多余的，因为如果您将表视为实体，而将列视为该实体的属性或属性，则将其视为的ID属性，而Employee不是EmployeeID员工的属性。我不走了问我的同事他什么PersonAge或者PersonGender是。我问他他的年龄是多少。

因此，就像我说的那样，这是一场激烈的辩论，我们将继续对此进行讨论。我有兴趣获得一些新观点。

没关系。我从来没有遇到过选择1和选择2真正有区别的系统。

杰夫·阿特伍德（Jeff Atwood）在该主题上发表了一篇不错的文章。基本上，人们最激烈地辩论和争论那些不能被证明是错误的话题。或者从另一个角度来看，那些只能通过基于前人站立论据的耐力风格耐力来赢得的主题。

选择一个，告诉他们专注于实际上影响您的代码的问题。

编辑：如果您想玩得开心，请让他们详细说明为什么他们的方法对递归表引用更优越。

如果两列在两个表中都具有相同的名称（惯例2），则可以在SQL中使用USING语法来节省一些键入内容和一些样板噪声：

SELECT name, address, amount
  FROM employees JOIN payroll USING (employee_id)

支持约定2的另一个论点是，这是关系模型的设计方式。

每列的重要性通过用相应域的名称标记来部分传达。

我认为这取决于您如何将应用程序组合在一起。如果您使用ORM或设计表来表示对象，那么选项1可能适合您。

我喜欢将数据库编码为自己的层。我控制一切，该应用程序仅调用存储过程。具有完整列名的结果集非常好，尤其是当有许多表联接并且返回了许多列时。对于这种类型的应用程序，我喜欢选项2。我非常喜欢看到联接上的列名匹配。我曾经在旧系统上工作，而旧系统却不匹配，这是一场噩梦，

两种约定在所有情况下均不起作用，那么为什么要全部采用？使用常识...

例如，对于自引用表，当有多个以上的FK列可对同一表的PK进行自引用时，您将违反两个“标准”，因为两个FK列不能命名为相同的…… ，具有EmployeeId PK，SupervisorId FK，MentorId Fk，PartnerId FK的EmployeeTable ...

我同意，他们之间几乎没有选择。对我而言，关于任何一个标准的更重要的事情是“标准”部分。

如果人们开始“做自己的事”，他们应该被他们的地狱所str住。恕我直言 ：）

您考虑过以下内容吗？

Primary Table (Employee)   
Primary Key is PK_Employee

Foreign table (Event)  
Foreign key is called FK_Employee

我们在工作的地方使用的约定与A非常接近，除了我们以复数形式（即“员工”）命名表，并在表名和列名之间使用下划线。这样做的好处是，引用一列可以是“ employees _ id”或“ employees.id”，具体取决于您要如何访问它。如果您需要指定该列来自哪个表，则“ employees.employees _ id”绝对是多余的。

如果您正在查看应用程序代码，而不仅仅是数据库查询，那么对我来说，有些事情似乎很清楚：

1. 表定义通常直接映射到描述一个对象的类，因此它们应该是单数。为了描述对象的集合，我通常在单数名称后附加“ Array”或“ List”或“ Collection”，因为比使用复数更清楚地表明它不仅是一个集合，而且还表示哪种集合它是。在该视图中，我看到的表名称不是集合的名称，而是集合的对象类型的名称。不编写应用程序代码的DBA可能会错过这一点。

2. 我处理的数据通常将“ ID”用于非密钥识别目的。为了消除键“ ID”和非键“ ID”之间的混淆，对于主键名，我们使用“ Key”（即它的名字，不是吗？），以表名或缩写为表名。该前缀（我仅将其保留给主键）使键名唯一，这尤其重要，因为我们使用的变量名与数据库列名相同，并且大多数类都有一个父级，由父键。这也需要确保它不是保留关键字，仅“ Key”就是保留关键字。为了便于保持键变量名称的一致性，并提供执行自然连接的程序，外键的名称与表中的主键相同。我遇到了不止一次的程序，这些程序使用自然联接可以更好地工作。关于这一点，我承认我使用的自引用表存在问题。在这种情况下，我将外键命名规则作为例外。例如，我将ManagerKey用作Employee表中的外键指向该表中的另一条记录。

我喜欢约定＃2-在研究此主题时，在发布自己的问题之前发现了这个问题，我遇到了以下问题：

我从具有大量列的表中选择*，并将其连接到同样具有大量列的第二个表中。这两个表都有一个“ id”列作为主键，这意味着我必须专门挑选每一列（据我所知），以使这两个值在结果中唯一，即：

SELECT table1.id AS parent_id, table2.id AS child_id

虽然使用约定＃2手段我仍然会在具有相同名称的结果某些列，我现在可以指定该 ID我需要（父母或子女），正如史蒂芬Huwig建议，该USING语句简化的东西进一步。

我一直使用userId在一个表上将用作PK，在另一个表上将userId用作FK。我正在认真考虑使用userIdPK和userIdFK作为名称来彼此标识。在查看表时，它将帮助我快速识别PK和FK，并且看起来当使用PHP / SQL访问数据时，它将清除代码，从而更易于理解。特别是当其他人查看我的代码时。

我使用约定＃2。我现在正在使用旧式数据模型，在该模型中我不知道给定表中的含义。冗长的地方有什么害处？

如何命名外键

角色编号

其中角色是引用实体相对于当前表的角色。这解决了递归引用和对同一表的多个fks的问题。

在许多情况下将与引用的表名称相同。在这种情况下，它与您的建议之一相同。

无论如何，长期争论是一个坏主意

“在“员工INNER JOIN订单ON order.employee_id = employee.id”中，是否需要其他资格？

不需要额外的资格认证，因为我所说的资格认证已经存在。

“业务用户引用订单ID或雇员ID的原因是为了提供上下文，但是在dabase级别，您已经具有上下文，因为您正在引用表”。

祈祷，告诉我，如果该列被命名为“ ID”，那么该“引用表”是如何精确完成的，除非完全按照我所说的方式对ID列的引用进行限定？