数据库设计中用table_id还是id更常用

Question

我有一种情况想知道使用 table_id 还是只使用 id 更常见？ （在我看来，如果它是外键，使用 table_ 会引起轻微的混淆）。 人们更喜欢哪一个，两者之间真的有什么区别吗？ 还是应该只选择一个并保持一致？

Answer 1

在命名表中的列方面有两个主要趋势：

架构命名空间

该策略是 70 年代记录数据库“数据字典”的团队构想的传统策略。 这个想法是列的名称本身告诉您它在整个模式或数据库中属于哪个表。 例如， CLIENT_NAME代表CLIENT表中的客户端名称。

这种策略有多种变体，其中有限数量的字母被指定为前缀（特别是对于 M:N 关系表），因为当时许多数据库中的列名被限制为 6 或 8 个字符。 例如，客户购买汽车的日期可以采用CLI_CAR_DATE 、 CLICAR_DATE甚至CLCADT的形式。

例子：

• 实体表“car”的主键“id”列将命名为CAR_ID 。
• 指向“car”的子表“document”上的外键将采用相同的形式： CAR_ID 。 这允许使用自然连接； 然而，应该指出的是，有令人信服的理由不惜一切代价避免自然连接，此处不予讨论。
• 与“person”有多个（两个）关系（卖方和买方）的表“transfer”上的外键会污染此策略。 它们可以命名为： PERSON_BUYER_ID和PERSON_SELLER_ID因为两者不能具有相同的名称PERSON_ID ； 它不再允许自然连接（好）。

表命名空间

在此策略（较新的）中，列名不包括它们所属的实体的名称，而仅包括它们的属性名称。 此策略更符合 object 设计，并生成更短的名称（即更少键入）。 提及列时必须注明表名。 例如，您需要在表CLIENT上说出列NAME 。

例子：

• 实体表“car”的主键“id”列将命名为ID 。
• 指向“car”的子表“document”上的外键将采用以下形式： CAR_ID ； 这与之前的策略相同。
• 与“person”有多个（两个）关系（卖方和买方）的表“transfer”上的外键可以命名为： BUYER_ID和SELLER_ID 。 他们可以像以前的策略一样遵循较长的名称，但这里的目标通常是使用较短的名称，以便应用程序源代码更易于编写和调试。

概括

我个人喜欢第二种，但有些球队同时采用这两种策略，而且没有明显的赢家。 我倾向于第二个 [我认为] 第一个的缺点是名称更长（输入更多）、更长的 SQL（更多错误）、神秘名称（它们不能很好地与 ORM 和应用程序对象一起使用）和外键不能很好地遵循策略。 事实上，无论具体实体如何，我数据库中的几乎所有主键都被命名为ID 。

但另一方面，一些团队非常重视仅通过查看就知道列的表名的想法。 这对于可能变得相当复杂的大型数据库（具有 200-1000 个关系事实表）非常有用，特别是对于团队的新成员。

但最重要的是，选择一个并保持一致。