数据库表中 ID 列的命名

Question

我想知道人们对数据库表中 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，那么它位于哪个表上是否显而易见？

其他人对这个话题有什么想法？

Answer 1

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

至于连接表而不知道哪个Id字段属于哪个表，在我看来，应该编写查询来处理这种情况。 在我工作的地方，我们总是在语句中使用的字段前面加上表/表别名。

Answer 2

最近我公司里就这件事发生了一场书呆子争论。 LINQ 的出现使得冗余的表名+ID 模式在我看来更加明显愚蠢。 我认为大多数理性的人都会说，如果您以必须指定表名来区分 FK 的方式手动编写 SQL，那么这不仅可以节省打字时间，而且还可以节省时间。仅使用 ID 可以使 SQL 更加清晰，因为您可以清楚地看到哪个是PK，哪个是FK。

例如，

FROM Employees e
LEFT JOIN Customers c ON e.ID = c.EmployeeID

不仅告诉我两者是相关的，而且还告诉我哪个是PK，哪个是FK。 而在旧风格中，你被迫要么看起来要么希望它们被命名得好。

Answer 3

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 字段，这种意外错误发生的可能性要小得多，而且更容易发现。

Answer 4

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

Answer 5

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

然而，我想补充一个最近更加重视这一论点的原因。

在我目前的职位上，我们正在使用 POCO 生成的实体框架。 使用 Id 的标准命名约定，PK 允许继承带有验证的 poco 基类，例如共享一组公共列名的表。 使用 Tablename + Id 作为每个表的 PK 会破坏使用这些表的基类的能力。

只是一些值得深思的东西。

Answer 6

这并不重要。 您可能会在所有命名约定中遇到类似的问题。

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

Answer 7

我的偏好也是主键 ID 和外键 TableNameID。 我还喜欢在大多数表中都有一个“名称”列，其中保存条目的用户可读标识符（即名称:-)）。 这种结构为应用程序本身提供了很大的灵活性，我可以用同样的方式处理大量的表。 这是一个非常强大的东西。 通常OO软件是建立在数据库之上的，但是OO工具集无法应用，因为数据库本身不允许。 拥有列 id 和 name 仍然不是很好，但这是一个步骤。

选择
i.ID , il.ID 来自
发票我
左连接发票行 il
i.ID = il.InvoiceID

为什么我不能这样做？

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

在我看来，这是非常易读且简单的。 一般来说，将变量命名为 i 和 il 是一个糟糕的选择。

Answer 8

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

在一种情况下，查询使用“... where ID in (SELECT ID FROM OtherTable ...”而不是“... where ID in (SELECT TransID FROM OtherTable ...”)。

任何人都可以诚实地说这不会有如果在错误语句为“... where TransID in (SELECT OtherTableID from OtherTable ...”的地方使用完整、一致的名称，那么更容易发现？我不这么认为。

重构代码时会出现另一个问题如果您使用临时表，而之前查询离开了核心表，则旧代码显示为“... dbo.MyFunction(t.ID) ...”，如果未更改，但“t”现在指的是。使用临时表而不是核心表，您甚至不会收到错误 - 只是错误的结果

如果生成不必要的错误是目标（也许有些人没有足够的工作？），那么这种命名约定很棒。否则，一致的命名是正确的选择。

Answer 9

我个人更喜欢（如上所述）PK的Table.ID和TableID FK。 甚至（请不要向我开枪）Microsoft Access 也推荐这样做。

然而，我也知道一些生成工具更喜欢使用 TableID 进行 PK，因为它们倾向于链接所有包含 'ID' 一词的列名，包括 ID！！！< /em>

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

因此，尽管我内心的强迫症讨厌它，但我遵循TableID约定。 让我们记住，它被称为数据BASE，因为它将成为未来许多应用程序的基础。 所有技术都应该受益于具有清晰描述模式的良好规范化。

不用说，当人们开始使用 TableName、TableDescription 等时，我确实会划清界限。 在我看来，惯例应该做到以下几点：

• 表名：复数。 前任。 Employees

• 表别名：完整表名称，单数形式。 例如。

  SELECT 员工.*, 电子邮件.地址 
    FROM Members AS Employee LEFT JOIN eMails as eMail on Employee.eMailID = eMail.eMailID -- 我当然希望这里只有 eMail.ID...但是哦好吧 
    

[更新]

此外，此线程中有一些关于由于“某种关系”或角色而导致重复列的有效帖子。 例如，如果商店有一个 EmployeeID，它告诉我蹲下。 所以我有时会做一些类似Store.EmployeeID_Manager的事情。 当然它有点大，但至少人们不会疯狂地寻找表 ManagerID 或 EmployeeID 在那里做什么。 当查询是 WHERE 时，我会将其简化为：
从商店中选择 EmployeeID_Manager 作为 ManagerID

Answer 10

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

Answer 11

从正式数据字典的角度来看，我将数据元素命名为 invoice_ID。 通常，数据元素名称在数据字典中是唯一的，并且理想情况下始终具有相同的名称，但有时可能需要基于上下文的附加限定术语，例如名为 employee_ID 的数据元素可以使用两次在组织结构图中，因此分别符合 supervisor_employee_ID 和 sublined_employee_ID 的条件。

显然，命名约定是主观的并且是风格问题。 我发现 ISO/IEC 11179 指南是一个有用的起点。

对于 DBMS，我将表视为实体的集合（除了那些只包含一行的表，例如 cofig 表、常量表等），例如，我的 employee_ID 为键的表将被命名为 <代码>人员。 因此，TableNameID 约定立即对我不起作用。

我已经看到在大数据模型上使用的 TableName.ID=PK TableNameID=FK 样式，不得不说我发现它有点令人困惑：我更喜欢标识符的名称在整个 ie 中保持不变名称基于它恰好出现在哪个表中。需要注意的是，上述样式似乎在商店中使用，这些商店向每个IDENTITY（自动增量）列> 表，同时避免外键中的自然键和复合键。 这些商店往往没有正式的数据字典，也没有根据数据模型构建。 再说一次，这只是一个风格问题，我个人并不认同这个问题。 所以最终，它不适合我。

话虽如此，当表的名称提供这样做的上下文时，我可以看到有时从列名称中删除限定符的情况，例如名为 employee_last_name 的元素可能会简单地变为 last_name 在 Personnel 表中。 这里的基本原理是，域是“人们的姓氏”，并且更有可能与其他表中的 last_name 列进行 UNION 组合，而不是用作另一个表中的外键，但话又说回来......我可能会改变主意，有时你永远无法判断。 事情就是这样：数据建模一半是艺术，一半是科学。

Answer 12

关于这个问题已经有很多答案，但我想添加上面我没有看到的两件主要事情：

• 客户向您寻求支持。

很多时候，客户或用户甚至其他部门的开发人员遇到了障碍，并联系我们说他们在操作时遇到问题。 我们询问他们对哪条记录有疑问。 现在，他们在屏幕上看到的数据（例如包含客户名称、订单数量、目的地等的网格）是许多表格的聚合。 他们说他们在 id 83 方面遇到了麻烦。如果它只是被称为“id”，则无法知道它是什么、它是哪个表。

也就是说，一行数据没有给出任何指示它来自哪个表。 除非您碰巧非常了解数据库的架构（在复杂系统或被告知要接管的非绿地系统上很少有这种情况），否则即使您有更多数据，您也不知道 id=83 意味着什么例如姓名、地址等（甚至可能不在同一张表中！）。

该 ID 可能来自网格，也可能来自 API 中的错误，或者将错误消息转储到屏幕或日志文件的错误查询。

通常，开发人员只是将“ID”转储到列中，然后就忘记了它，并且数据库通常有许多类似的表，例如 Invoice、InvoiceGrouping、InvoicePlan，ID 可能适用于其中任何一个。 沮丧的是，您查看代码以查看它是哪一个，并发现他们也在模型上将其称为 Id，因此您必须深入研究页面模型的构建方式。 我无法计算出有多少次我必须这样做才能弄清楚 Id 是什么。 很多。 有时您还必须挖掘出一个仅返回“Id”作为标头的 SPROC。 恶梦。

• 当清楚出了什么问题时，日志文件会变得更容易

SQL 通常会给出非常糟糕的错误消息。 “无法插入 ID 为 83 的项目，列将被截断”或类似的内容很难调试。 通常错误消息并不是很有帮助，但通常损坏的东西会通过转储主键名称和值来模糊地尝试告诉您哪些记录被损坏。 如果它是“ID”，那么它根本没有帮助。

这只是我觉得其他答案中没有提到的两件事。

我还认为很多评论是“如果你以 X 方式编程，那么这不是问题”，并且我认为上面的观点（以及这个问题的其他观点）是有效的，特别是因为人们编程的方式，并且因为他们没有时间、精力、预算和远见来进行完美的日志记录和错误处理编程，也没有改变快速 SQL 和代码编写的根深蒂固的习惯。

Answer 13

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

 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

当然，它比其他一些例子更长。 但微笑吧。 这是为了子孙后代，有一天，一些可怜的初级程序员将不得不改变你的杰作。 在此示例中，没有任何歧义，并且随着附加表被添加到查询中，您将感谢它的冗长。

Answer 14

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

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

因此，名为 NAMES 的表可能具有字段 pk_name_id、first_name、last_name、is_alive 和 fk_company 和一个名为 LIVING_CUSTOMERS_VW 的视图，定义如下：

SELECT first_name, last_name
FROM CONTACT.NAMES
WHERE (is_alive = 'True')

不过，正如其他人所说，只要一致并且不会不必要地混淆您的含义，几乎任何方案都可以工作。

Answer 15

我绝对同意在 ID 字段名称中包含表名称，这正是您给出的原因。 一般来说，这是我唯一包含表名称的字段。

Answer 16

我确实讨厌简单的 id 名称。 我强烈喜欢始终使用发票 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 。 那简直就是地狱。

Answer 17

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

第一条语句的意思是，您可以使用“recno”等其他内容来代替 ID。 那么这个表就会有invoice_recno 的PK 等等。

干杯，
本

Answer 18

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

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

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

Answer 19

如果您为每个键指定一个唯一的名称，例如“invoices.invoice_id”而不是“invoices.id”，那么您可以毫无顾虑地使用“自然连接”和“using”运算符。 例如，

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 已经足够冗长，但不会使其变得更冗长。

Answer 20

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

对我来说，这很有意义，特别是对于我认为读起来更容易的连接。

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

Answer 21

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

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

ID 本身的问题在于它无法向上扩展。 一旦您拥有大约 200 个表，每个表都有一个名为 ID 的第一列，数据就开始看起来很相似。 如果您始终使用表名来限定 ID，这会有一点帮助，但没有那么大。

域名 & ID 可用于命名外键和主键。 当外键以其引用的列命名时，这可以提供助记帮助。 形式上，不必将外键的名称与其引用的键绑定在一起，因为引用完整性约束将建立引用。 但在读取查询和更新时它非常方便。

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

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

Answer 22

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

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

优点是不同表中的标识列不会产生歧义，并且您可以通过列名一眼看出查询引用的是哪些列。

Answer 23

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

这样数字自动编号主键就变成了nkEmp。

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

我在 SQL 和我使用的所有语言（主要是 C#、Javascript、VB6）中保留相同的名称。

Answer 24

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

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

这样你就可以说

SELECT * FROM Invoice LEFT JOIN InvoiceLines ON inv_id = invl_inv_id