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

时间:2008-10-17 22:26:29

标签: sql naming-conventions foreign-keys

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

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

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

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

6 个答案:

答案 0 :(得分:7)

我同意你的看法。将这些信息放在列名中,就会出现早期Windows时代蹩脚的匈牙利符号愚蠢。

答案 1 :(得分:6)

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

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),
  ...
);

我不想在列名中包含表的名称。我还避免将强制性“id”作为每个表中主键列的名称。

答案 2 :(得分:5)

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

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

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

忽略复合主键,我不明白为什么像“id”这样简单的东西不足以满足主键,而“_id”则不适用于外键。

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

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

答案 3 :(得分:1)

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

答案 4 :(得分:0)

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

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

有一个好的!

答案 5 :(得分:-1)

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

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

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

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