数据库表中ID列的命名

我想知道人们对数据库表中ID列的命名有何看法。

如果我有一个名为Invoices的表，且其标识列的主键为该表，则应将该列称为InvoiceID，这样我就不会与其他表发生冲突，这很明显。

在我目前工作的地方，他们已经将所有ID列称为ID。

因此，他们将执行以下操作：

Select  
    i.ID 
,   il.ID 
From
    Invoices i
    Left Join InvoiceLines il
        on i.ID = il.InvoiceID

现在，我在这里看到一些问题：
1.您将需要对select的列进行别名
2. ID = InvoiceID不适合我的大脑
3.如果您未对表进行别名并引用InvoiceID，那么显然是哪个表它开着？

其他人对此话题有何看法？

ID是一个SQL反模式。参见http://www.amazon.com/s/ref=nb_sb_ss_i_1_5?url=search-alias%3Dstripbooks&field-keywords=sql+antipatterns&sprefix=sql+a

如果您有许多ID为ID的表，那么报告工作将变得更加困难。它掩盖了含义，使复杂的查询更难以阅读，并且要求您使用别名来区分报告本身。

此外，如果某人愚蠢到可以在可用的数据库中使用自然联接，那么您将联接到错误的记录。

如果要使用某些数据库允许使用的USING语法，则使用ID则不能。

如果使用ID，如果您恰巧正在复制连接语法（不要告诉我，没有人这样做！），那么很容易以错误的连接结尾，而忘记在连接条件中更改别名。

所以你现在有

select t1.field1, t2.field2, t3.field3
from table1 t1 
join table2 t2 on t1.id = t2.table1id
join table3 t3 on t1.id = t3.table2id

当你的意思

select t1.field1, t2.field2, t3.field3 
from table1 t1 
join table2 t2 on t1.id = t2.table1id
join table3 t3 on t2.id = t3.table2id

如果将tablenameID用作id字段，则这种意外错误的发生率将大大降低，并且更容易发现。

我总是更喜欢ID而不是ID列的TableName + ID，然后是外键的TableName + ID。这样，所有表的id字段都具有相同的名称，并且没有多余的描述。对我来说，这似乎更简单，因为所有表都具有相同的主键字段名称。

至于连接表，并且不知道哪个Id字段属于哪个表，我认为应该编写查询来处理这种情况。在我工作的地方，我们总是将在表/表别名的语句中使用的字段优先。

最近在我的公司里，关于这件事的争论很激烈。LINQ的出现使冗余表名+ ID模式在我眼中显得更加愚蠢。我认为大多数理性的人都会说，如果您以某种方式来编写SQL，即必须指定表名来区分FK，那么不仅节省了键入时间，而且还使SQL的使用更加清晰明了。通过ID，您可以清楚地看到哪个是PK，哪个是FK。

例如

来自员工e左加入客户c ON e.ID = c.EmployeeID

不仅告诉我两者是链接的，而且还告诉我PK和FK。而在旧样式中，您不得不外观或希望它们被命名为好。

我们使用InvoiceID而不是ID。它使查询更具可读性- ID仅当您看到它时，它可能具有任何意义，尤其是当您将表别名为时i。

我同意凯文（Keven）和其他一些人的观点，表的PK应该只是ID，外键列出OtherTable + Id。

但是，我想补充一个理由，该理由最近更加重视了这一论点。

在我目前的职位上，我们正在使用通过POCO生成的实体框架。使用Id的标准命名约定，PK允许通过验证继承基poco类，并且对于共享一组公共列名的表也是如此。将这些表中的每个表都使用Tablename + Id作为PK会破坏对这些表使用基类的能力。

只是需要一些思考。

我的首选项也是主键的ID和外键的TableNameID。我还喜欢在大多数表中都有一个“名称”列，其中保存着该条目的用户可读标识符（即名称：-）。这种结构为应用程序本身提供了极大的灵活性，我可以用相同的方式处理大量表。这是非常强大的事情。通常，OO软件是基于数据库构建的，但是OO工具集无法应用，因为db本身不允许这样做。具有列ID和名称仍然不是很好，但这是一个步骤。

从发票i中选择i.ID，il.ID。i.ID = il.InvoiceID上的左联接发票行il

为什么我不能这样做？

Select  
    Invoices.ID 
,   InvoiceLines.ID 
From
    Invoices
    Left Join InvoiceLines
        on Invoices.ID = InvoiceLines.InvoiceID

我认为这是非常易读和简单的。通常，将变量命名为i和il是一个糟糕的选择。

这并不是很重要，您可能会在所有命名约定中遇到较小的问题。

但是保持一致很重要，这样您不必在每次编写查询时都查看表定义。

我刚刚开始在仅使用“ ID”的位置（在核心表中，由外键中的TableNameID引用）工作，并且已经发现了两个直接由它引起的生产问题。

在一种情况下，查询使用“ ...在（SELECT ID从其他表中选择ID ...”中的ID，而不是“ ...在（SELECT TransID来自其他表中ID中的ID）”。

任何人都可以诚实地说，如果使用完整，一致的名称，在错误的语句显示为“ ... where TransID in（SELECT OtherTableID from OtherTable ...”中的位置），发现这一点不会容易得多吗？所以。

重构代码时会发生另一个问题。如果您使用临时表，而以前查询不在核心表中，那么旧代码将读取“ ... dbo.MyFunction（t.ID）...”，如果未更改，但“ t”现在表示一个临时表而不是核心表，您甚至都不会得到错误-只是错误的结果。

如果产生不必要的错误是目标（也许有些人工作量不足？），那么这种命名约定就很棒。否则，要保持一致的命名方式。

为了简单起见，大多数人在表ID上命名该列。如果它在另一个表上具有外键引用，那么在连接的情况下，他们会显式地将其称为InvoiceID（以您的示例为例），无论如何您都在对该表进行别名操作，因此显式的inv.ID仍然比inv.InvoiceID更简单。

我个人比较喜欢（因为已经如上所述）的Table.ID的PK和表格ID为FK。甚至（请不要射击我）Microsoft Access都建议这样做。

但是，我也知道一些生成工具偏爱PK的TableID的事实，因为它们倾向于链接单词中包含“ ID”的所有列名，包括ID！

甚至查询设计器也在Microsoft SQL Server上执行此操作（对于您创建的每个查询，您最终都会在列ID的所有表上剥夺所有不必要的新创建的关系）

尽管我的内部OCD讨厌它，但我还是遵循TableID约定。让我们记住，这就是所谓的数据基础，因为这将是希望很多很多很多的应用程序来的基础。并且所有技术都应该受益于规范化，描述清晰的架构。

不用说，当人们开始使用TableName，TableDescription等时，我确实会划清界限。我认为，约定应执行以下操作：

• 表名：复数。例如 雇员

• 表别名：全表名，单数。例如

  SELECT Employee.*, eMail.Address
  FROM Employees AS Employee LEFT JOIN eMails as eMail on Employee.eMailID = eMail.eMailID -- I would sure like it to just have the eMail.ID here.... but oh well

[更新]

另外，由于“某种关系”或角色，此线程中有一些关于重复列的有效帖子。例如，如果商店有一个EmployeeID，那就告诉我蹲下。所以有时我会做类似Store.EmployeeID_Manager的事情。当然，它会更大一些，但是，人们至少会发现表ManagerID或EmployeeID在做什么的想法不会发疯。当查询在哪里时，我将其简化为：SELECT EmployeeID_Manager作为ManagerID FROM Store

从正式数据字典的角度来看，我将命名数据元素invoice_ID。通常，数据元素名称在数据字典中将是唯一的，并且理想情况下在整个名称中应具有相同的名称，尽管有时可能会根据上下文要求附加限定词，例如，命名的数据元素employee_ID可在组织结构图中使用两次，因此限定为supervisor_employee_ID和subordinate_employee_ID分别。

显然，命名约定是主观的并且是样式问题。我发现ISO / IEC 11179准则是一个有用的起点。

对于DBMS，我将表视为实体的集合（除了仅包含一行的实体，例如cofig表，常量表等），例如，employee_ID将以my 为键的表命名为Personnel。因此，TableNameID常规对我不起作用。

我已经看过TableName.ID=PK TableNameID=FK大型数据模型上使用的样式，不得不说我觉得有点困惑：我更喜欢标识符的名称在整个过程中都是相同的，即不会根据碰巧出现在哪个表上而更改名称。在商店中使用上述样式似乎是在商店中使用的，它们IDENTITY在每张表中都增加了一个（自动递增）列，同时避免了外键中的自然键和复合键。这些商店往往没有正式的数据字典，也没有从数据模型构建的倾向。再说一次，这只是一个风格问题，我个人不赞成。所以最终，这不适合我。

综上所述，当表的名称提供了这样做的上下文时，例如当命名的元素employee_last_name可能last_name在Personnel表中变得简单时，我可以看到有时从列名中删除限定符的情况。这里的理由是，域名是“人的姓氏”，更可能被UNION埃德last_name列从其他表，而不是作为一个外键的另一个表，但随后又......我可能只是改变了主意，有时你永远无法分辨。就是这样：数据建模既是艺术，又是科学。

我认为只要您保持一致，就可以为“ ID”使用任何内容。包括表名很重要。我建议使用诸如Erwin之类的建模工具来强制执行命名约定和标准，因此在编写查询时，很容易理解表之间可能存在的关系。

我所说的第一句话是，您可以使用诸如“ recno”之类的东西代替ID。因此，此表将具有invoice_recno的PK，依此类推。

干杯本

我的投票是针对表ID的InvoiceID。当用作外键时，我也使用相同的命名约定，并在查询中使用智能别名。

 Select Invoice.InvoiceID, Lines.InvoiceLine, Customer.OrgName
 From Invoices Invoice
 Join InvoiceLines Lines on Lines.InvoiceID = Invoice.InvoiceID
 Join Customers Customer on Customer.CustomerID = Invoice.CustomerID

当然，它比其他示例更长。但是，微笑。这是为了后代，有朝一日，一些可怜的初级编码员将不得不改变您的杰作。在此示例中，不存在歧义，并且随着向查询中添加其他表，您将非常感谢您的冗长。

对于数据库中的列名，我将使用“ InvoiceID”。

如果我通过LINQ将字段复制到一个未命名的结构中，那么如果它是结构中的唯一ID，则可以在其中将其命名为“ ID”。

如果该列不打算用在外键中，那么它仅用于唯一地标识要编辑或删除的行，则将其命名为“ PK”。

如果为每个键指定一个唯一的名称，例如“ invoices.invoice_id”而不是“ invoices.id”，则可以使用“自然联接”和“使用”运算符而不必担心。例如

SELECT * FROM invoices NATURAL JOIN invoice_lines
SELECT * FROM invoices JOIN invoice_lines USING (invoice_id)

代替

SELECT * from invoices JOIN invoice_lines
    ON invoices.id = invoice_lines.invoice_id

SQL足够冗长而又不那么冗长。

为了使自己保持一致（在表中有一个单列主键用作ID），我要做的就是命名表的主键Table_pk。在任何有指向该表主键的外键的地方，都称为column PrimaryKeyTable_fk。这样，我知道如果Customer_pk我的客户表和Customer_fk订单表中都有一个，则我知道该订单表引用了客户表中的一个条目。

对我而言，这尤其适用于我认为更容易理解的联接。

SELECT * 
FROM Customer AS c
    INNER JOIN Order AS c ON c.Customer_pk = o.Customer_fk

FWIW，我们的新标准（随着每个新项目的变化，呃，我的意思是“演变”）是：

• 小写数据库字段名称
• 大写表格名称
• 使用下划线分隔字段名称中的单词-在代码中将其转换为Pascal大小写。
• pk_ 前缀表示主键
• _id 后缀表示一个整数，自动递增的ID
• fk_ 前缀表示外键（无需后缀）
• _VW 查看后缀
• is_ 布尔值的前缀

因此，一台名为名称可能有田pk_name_id, first_name, last_name, is_alive,和fk_company以及一个名为视图LIVING_CUSTOMERS_VW，等被定义：

选择名字，姓氏
来自CONTACT.NAMES
在哪里（is_alive ='True'）

但是，正如其他人所说，只要方案是一致的，并且不会不必要地混淆您的意思，那么几乎任何方案都将起作用。

出于您给出的确切原因，我绝对同意在ID字段名称中包含表名称。通常，这是我要包含表名称的唯一字段。

我讨厌简单的ID名称。我强烈希望始终使用invoice_id或其变体。我总是知道哪个表是ID的权威表，但这使我感到困惑

SELECT * from Invoice inv, InvoiceLine inv_l where 
inv_l.InvoiceID = inv.ID 
SELECT * from Invoice inv, InvoiceLine inv_l where 
inv_l.ID = inv.InvoiceLineID 
SELECT * from Invoice inv, InvoiceLine inv_l where 
inv_l.ID = inv.InvoiceID 
SELECT * from Invoice inv, InvoiceLine inv_l where 
inv_l.InvoiceLineID = inv.ID 

最糟糕的是您提到的混合，完全令人困惑。我不得不使用一个数据库，除了最常用的ID之一外，几乎几乎都是foo_id。那简直是地狱。

我更喜欢域名|| 'ID'。（即域名+ ID）

DomainName通常但并非总是与TableName相同。

ID本身的问题在于它不会向上扩展。一旦有了大约200个表，每个表都有第一列名为ID的表，数据就开始看起来完全一样。如果您总是用表名来限定ID，那会有所帮助，但没有太大帮助。

DomainName和ID可用于命名外键和主键。当foriegn键在它们所引用的列之后命名时，这可能有助于记忆。正式地，没有必要将外键的名称与其引用的键绑定在一起，因为引用完整性约束将建立引用。但是，在阅读查询和更新时非常方便。

有时，域名|| 不能使用“ ID”，因为同一表中会有两列具有相同的名称。示例：Employees.EmployeeID和Employees.SupervisorID。在那种情况下，我使用RoleName ||。如示例中的“ ID”。

最后但并非最不重要的一点是，我尽可能使用自然键而不是合成键。在某些情况下自然键不可用或不可信，但是在很多情况下自然键是正确的选择。在这种情况下，我让自然键采用自然拥有的名称。此名称通常甚至都没有字母“ ID”。示例：OrderNo，其中No是“ Number”的缩写。

对于每个表，我选择一个树字母速记（例如，Employees => Emp）

这样，数字自动编号主键将成为nkEmp。

它很短，在整个数据库中都是唯一的，我一眼就知道它的属性。

我在SQL和我使用的所有语言（大多数是C＃，Javascript，VB6）中保持相同的名称。

请参阅Interakt网站的命名约定，以获取周到的命名表和列的系统。该方法为每个表（_prd产品表或_ctg类别表）使用后缀，并将后缀附加到给定表的每个列中。因此，产品表的标识列将是id_prd并且因此在数据库中是唯一的。

他们进一步走了一步，以帮助理解外键：在产品表中引用类别表的外键应该是idctg_prd这样，这样就很明显它属于哪个表（_prd后缀）以及它所引用的表（类别）。 。

优点是，不同表中的标识列之间没有歧义，并且您可以一眼就知道查询是通过列名引用的列。

另请参见主键/外键命名约定

您可以使用以下命名约定。它有缺陷，但可以解决您的特定问题。

1. 使用简短的（3-4个字符）昵称作为表格名称，即invInvoice-，InvoiceLines-invl
2. 使用这些绰号，即在命名表中的列inv_id，invl_id
3. 对于参考列，请使用invl_inv_id名称。

这样你可以说

SELECT * FROM Invoice LEFT JOIN InvoiceLines ON inv_id = invl_inv_id