为什么在列名前面加上表名是一种惯例？

Question

我在很多数据库中都看到过这种约定，但它是多余的。一些答案说这是为了减少复杂连接期间的混乱，但这并不是一个充分的理由。如果要进行复杂的连接，请创建别名。

连接真的代表了这样一个常见的任务，以至于我们应该使选择、插入和更新等标准任务变得多余吗？

为什么在列名前面加上表名是一种惯例？

Answer 1

我认为实际上并不存在用表名作为列名前缀的约定。

正如 Philippe Grondier 详细介绍的那样，数据建模的“正确”方法是首先创建数据元素名称的字典。遵循国际标准 ISO 11179 指南：

[Object] [Qualifier] Property RepresentationTerm

您最终会得到完全合格的数据元素。这里的限定符元素 Object、Qualifier 以及有时的 Property 是您认为的“前缀”的组合。

在 SQL 中实现数据模型时，表名可以提供上下文并引导设计者从列名中删除限定术语。我认为这是您更喜欢的约定。**

换句话说，在您质疑的约定中，并不是表名已作为列名的前缀，而是保留了限定术语。

---

** 无论您的约定还是任何其他约定是否良好都是主观的，Stackoverflow 不是进行此类讨论的场所。不过，我要顺便提一下，保留限定条件确实有实际好处（并且理论上合理），例如，考虑到 SQL 的NATURAL JOIN 适合在整个模式中一致命名的列。

Answer 2

确实，这种“开发的列名称”方法广泛用于列命名，例如，Tbl_Person 将具有 id_Person 主键列和 personName 文本列。

虽然一开始写“开发”列名（如“id_Person”、“personName”、“personAdress”等）可能看起来相当痛苦，但当您必须在多个表上编写 SELECT 时，一切都会变得更加清晰，这是每次都会发生的事情您打开表格或报告。

这种“开发的列名称”方法还有一个理论/历史维度。第一个关系数据库理论和方法（如 MERISE）提出，作为第一步，构建所谓的“数据字典”，即应用程序\数据库要操作的所有数据的列表。

甚至在提出任何“实体-关系”模型之前就必须建立该字典。 数据名称/描述必须得到充分开发，这是为了避免“相似”数据条目之间的混淆，例如“companyName”和“personName”。

因此，“开发的列名称”约定反映了这样一个事实：在数据级别，相似的列（例如 Company.name 和 Person.name 列）< strong>并不像看起来那样等效。虽然它们看上去都是为了持有名字而来，但其中一个是为了持有公司名称，而另一个则是为了持有个人名字！

这种约定可以被认为是反映数据库每个列的确切含义，或者反映数据字典中每个条目的确切含义的一种方式。

Answer 3

我从未见过带前缀的完整表名，但通常至少有一个缩写。你是完全正确的，这是为了简化连接等。例如，始终写 ur_id 比有时写 id 和其他时候写 userrights.id 更容易。一次需要访问多个表的情况并不少见。

Answer 4

连接是选择的一部分，因此比较不成立。

除此之外，我认为您不应该在字段前加上表名作为前缀，主键除外。我喜欢给每个表一个代理键，我宁愿以表的名字命名。因此表“Orders”将获得“OrderId”PK。订单行将有一个外键 OrderId 来指向订单。这样，各个表中的字段名称都是相同的，您可以通过名称来判断它显示了哪些数据。您可以在所有表​​中将该字段命名为“Id”，但您必须读取别名才能了解您指的是哪个 ID。我写的一些查询超过 400 行。您不想单独依赖表别名。字段名本身的一些上下文确实有帮助。

Answer 5

这不是一个惯例；而是一个惯例。有些人这样做，有些人不这样做。我更经常看到 ID 列以表名为前缀，但没有其他列。一些（全部？）数据库还允许在查询中使用表名作为前缀，但这既不是必需的，也不是实际列名的一部分。

Answer 6

我不喜欢这样的命名约定。它鼓励懒惰，特别是在查询中使用不合格的引用。为查询中的每个表使用别名，并使用适当的别名限定每个列引用。

我唯一喜欢的命名约定与主键/外键有关：

• 我喜欢将主键命名为一些巧妙的名称，例如 id。
• 我喜欢用包含主键的表的名称作为外键列名称的名称前缀。

恕我直言，它使 SQL 变得更加清晰。一个例子：

   create table foo
   (
     id int not null primary key ,
     ...
   )

   create table bar
   (
     id int not null primary key ,
     foo_id int not null foreign key references foo (id) ,
     ...
   )

   select *
   from foo foo
   join bar bar on bar.foo_id = foo.id

当然，当你使用复合键时，这个方案就会失败。但我喜欢它。 YMMV。

Answer 7

除了其他人所说的之外，在识别关系（也称为识别外键）的情况下，它还使事情变得更简单。

标识关系将父级主键“迁移”到子级主键的一部分。前缀可确保不会发生冲突，并且即使存在多个级别的标识关系，您也无需重命名迁移的字段。例如：

PARENT:
    PARENT_NAME      PK

CHILD:
    PARENT_NAME      PK, FK referencing PARENT
    CHILD_NAME       PK

GRANDCHILD:
    PARENT_NAME      PK, FK referencing CHILD
    CHILD_NAME       PK, FK referencing CHILD
    GRANDCHILD_NAME  PK

在整个数据模型中保持相同的名称可以避免对字段的含义和来源产生任何混淆。

另一方面，前缀可能会影响可读性，因此我通常会采取妥协：为主键字段添加前缀，但其他字段不添加前缀。

Answer 8

特殊情况

正如其他人指出的那样，没有强制理由这样做。通过完整的 schema.table.col 约定可以轻松消除歧义。

不过，有一个实际原因，即当您的物理环境使用 MySQL 方言作为 DML 时。这种语言类型方便地支持 JOIN 中的 USING
clause 这使得更容易编写和阅读语句。

进行比较

将关系 t1 与 PK t1_ID 和 t2 与 PK t2_ID 和 FK t1_ID 代码>

SELECT t1.a, t2.b
FROM t1
INNER JOIN t2 USING(t1_ID)

和
关系 t1 带有 PK ID，t2 带有 PK ID 和 FK t1_ID >

SELECT t1.a, t2.b
FROM t1
INNER JOIN t2 on t1.ID = t2.t1_ID

看起来差别很小，但表名较长，版本一提供了稍微更好的可读性，因此不易出错的代码。