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

一些最近的问题讨论了命名列的策略，我很惊讶地发现在列名中嵌入外键和主键的概念。也就是说为什么在列名中指定主键/外键属性

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

......知道哪一个是外键是重要的吗？外键仅对数据库引擎本身很重要，以确保参照完整性并在更新和删除过程中做正确的事情。

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

来源

2008-10-17 dland

我同意你的子表中的外键列应该与父表中的主键列具有相同的名称。请注意，这允许类似下面的语法：

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”作为每个表中主键列的名称。

来源

2008-10-17 23:17:20

我同意你的意见。将这些信息放在栏目名称中，以表示早期Windows时代的糟糕的匈牙利符号白痴。

来源

2008-10-17 22:31:28

-1

我同意你的看法 - 我拿，我已经看到了许多企业环境推荐了不同的方法：在格式

名称列TableNameFieldName，所以如果我有一个客户表和用户名是一个我的字段，该字段将被称为CustomerUserName。这意味着如果我有另一个名为Invoice的表，并且客户的用户名是外键，我将其称为InvoiceCustomerUserName，当我引用它时，我将其称为Invoice.CustomerUserName，它立即告诉我它在哪个表中。

另外，这个命名可以帮助你跟踪你的列在来自你的时候的表格。

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

来源

2008-10-17 22:32:57

岂不它是Invoice.InvoiceCustomerUserName？这有可能比类型标签更糟...... Invoice.UserName = Customer.UserName对我来说似乎已经足够清晰了。 – 2008-10-17 22:55:46

对不起，这太可怕了。简直可怕。它看起来像是一种“巧妙”，可以避免使用表别名。几乎和我工作的地方一样糟糕，其中表名前缀为T_和列C_（视图和索引也有前缀...） – 2008-10-18 00:07:51

我在表的任何外键的前端使用“fk_”主要是因为它帮助我在开发商店项目的数据库时保持直线。过去没有做过任何数据库工作，这对我有帮助。事后看来，也许我不需要那么做，但是在某些专栏名称上加了三个字符，所以我没有出汗。作为编写数据库应用程序的新手，我可能做出了一些决定，这将使经验丰富的数据库开发人员感到不寒而栗，但我不确定外部关键事情真的是什么大不了的事情。再次，我想这是一个关于这个问题的观点上的差异，我一定会拿你写的和认真的。

有一个好的！

来源

2008-10-17 22:45:17 itsmatt

我只使用具有主键的Id后缀的表名，例如， CustomerId和引用其他表的外键也将被称为CustomerId。当你在应用程序中引用时，它很容易从对象属性中得到表格，例如Customer.TelephoneNumber，Customer.CustomerId等

来源

2008-10-17 22:48:01 Turnkey

在我用SQL数据库开发的20多年的时间里，我一直赞同这里提出的大多数想法，我很尴尬地说。他们中的大多数人提供了很少或没有预期的好处，并且事后看来是痛苦的脖子。

任何时候我花了超过几个小时的模式，我已经很快熟悉了最重要的表格和它们的列。一旦到了几个月，我就会把所有的东西都放在我的脑海里。

这是谁的全部解释？无论如何，只花费几分钟时间完成设计的人不会做任何事情。如果你用梵文命名你的专栏，那么计划长期使用它的人会学习它。

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

所以一个典型的连接条件变成customer.id = order.customer_id。

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

来源

2008-10-18 00:19:56

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

回答

相关问题