为什么在列名中指定主键/外键属性

StackOverflow https://stackoverflow.com/questions/214045

题

最近几个问题讨论了命名列的策略，我很惊讶地发现了在列名中嵌入外键和主键概念的概念。那是

select t1.col_a, t1.col_b, t2.col_z
from t1 inner join t2 on t1.id_foo_pk = t2.id_foo_fk

我必须承认我从来没有使用任何使用这种方案的数据库系统，我想知道它有什么好处。我看到它的方式，一旦你学会了系统的N个主表，你就会用这些表写出几个数量级的请求。

为了提高开发效率，您需要了解哪些表是重要的表，哪些表是简单的支流。您需要向内存提交大量列名。其中一个基本任务是将两个表连接在一起。为了减少学习工作，最简单的方法是确保两个表中的列名相同：

select t1.col_a, t1.col_b, t2.col_z
from t1 inner join t2 on t1.id_foo = t2.id_foo

我认为，作为一名开发人员，您不需要提醒您关于哪些列是主键，哪些列是外键而哪些列什么都不是。如果你很好奇的话，很容易看到架构。当看一个随机的

tx inner join ty on tx.id_bar = ty.id_bar

......知道哪一个是外键是否重要？外键仅对数据库引擎本身很重要，以允许它确保引用完整性并在更新和删除期间做正确的事情。

这里有什么问题要解决？ （我知道这是一个讨论的邀请，并随时可以这样做。但与此同时，我我正在寻找答案，因为我可能真的错过了一些东西。）

有帮助吗？

解决方案

我同意您的看法，子表中的外键列应与父表中的主键列具有相同的名称。请注意，这允许语法如下：

SELECT * FROM foo JOIN bar USING (foo_id);

USING关键字假定两个表中的列都存在相同的名称，并且您希望使用等连接。很高兴将它作为更详细的简写提供：

SELECT * FROM foo JOIN bar ON (foo.foo_id = bar.foo_id);

但是，请注意，有些情况下，您无法将外键命名为与其引用的主键相同。例如，在具有自引用的表中：

CREATE TABLE Employees (
  emp_id INT PRIMARY KEY,
  manager_id INT REFERENCES Employees(emp_id)
);

同样，表可能有多个外键到同一个父表。使用列的名称来描述关系的性质是有用的：

CREATE TABLE Bugs (
  ...
  reported_by INT REFERENCES Accounts(account_id),
  assigned_to INT REFERENCES Accounts(account_id),
  ...
);

我不想在列名中包含表的名称。我也避开了强制性的“身份证”。作为每个表中主键列的名称。

其他提示

我同意你的看法。把这些信息放在专栏名称中，就像早期Windows时代那种蹩脚的匈牙利符号愚蠢。

我一直支持这里提出的大多数想法，这些想法是我用SQL数据库开发的20多年，我很尴尬地说。他们中的大多数提供了很少或没有预期的好处，并且后见之明，颈部疼痛。

任何时候我花了超过几个小时的模式，我已经很快熟悉了最重要的表格及其专栏。一旦它持续了几个月，我几乎已经掌握了整个事情。

这是什么解释？只花几分钟完成设计的人无论如何都不会做任何严肃的事情。如果你用梵文命名列，那么计划长时间使用它的人将会学习它。

忽略复合主键，我不明白为什么像“id”这样简单的东西。对于主键是不够的，而“_id”也是不够的。对于外键。

因此，典型的连接条件变为 customer.id = order.customer_id 。

如果两个表之间存在多个关联，我倾向于使用关联而不是表名，所以也许是“parent_id”。和“child_id”而不是“parent_person_id”而不是“parent_person_id”。等

我只使用带有Id后缀的表名作为主键，例如CustomerId和引用其他表的外键也称为CustomerId。当您在应用程序中引用时，对象属性中的表变得明显，例如Customer.TelephoneNumber，Customer.CustomerId等

我使用了“fk_”在桌子的任何外键的前端，主要是因为它帮助我在为我的商店的项目开发数据库时保持正确。在过去没有完成任何数据库工作，这对我有帮助。事后看来，也许我不需要这样做，但是在一些列名上添加了三个字符，所以我没有出汗。

作为编写数据库应用程序的新手，我可能做出了一些让经验丰富的数据库开发人员不寒而栗的决定，但我不确定外键关键的东西是不是很重要。同样，我认为这个问题在观点上有所不同，我肯定会把你所写的内容与之相提并论。

有一个好的！

我同意你的观点 - 我采用了一种在许多企业环境中推荐的不同方法：

以 TableNameFieldName 格式命名列，因此如果我有一个Customer表而UserName是我的某个字段，则该字段将被称为CustomerUserName。这意味着如果我有另一个名为Invoice的表，并且客户的用户名是外键，我会称之为InvoiceCustomerUserName，当我引用它时，我会称之为Invoice.CustomerUserName，它会立即告诉我它在哪个表中。

此外，此命名可帮助您跟踪加入时列的来源表。

我只在DBMS中的外键和主键的ACTUAL名称中使用FK_和PK_。

许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top