3

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

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

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

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

4

6 回答 6

7

我同意你的看法。将此信息放在列名中带有早期 Windows 时代蹩脚的匈牙利符号白痴的味道。

于 2008-10-17T22:31:28.253 回答
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”作为每个表中主键列的名称。

于 2008-10-17T23:17:20.220 回答
5

在我用 SQL 数据库开发的 20 年里，我一直支持这里提出的大部分想法，我很尴尬地说。他们中的大多数人几乎没有或根本没有提供预期的好处，事后看来，这是一种颈部疼痛。

每当我在架构上花费了几个小时以上的时间时，我都会很快熟悉最重要的表及其列。一旦到了几个月，我几乎会把整个事情都放在我的脑海里。

这一切的解释是为了谁？一个只花几分钟设计的人无论如何都不会做任何严肃的事情。如果您用梵文命名您的列，那么计划长期使用它的人将会学习它。

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

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

在两个表之间存在多个关联的情况下，我倾向于使用关联而不是表名，因此可能是“parent_id”和“child_id”而不是“parent_person_id”等

于 2008-10-18T00:19:56.880 回答
1

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

于 2008-10-17T22:48:01.277 回答
0

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

作为一个编写数据库应用程序的新手，我可能做出了一些决定，这会让经验丰富的数据库开发人员不寒而栗，但我不确定外键是否真的有那么大。再说一次，我想这是对这个问题的看法不同，我肯定会接受你所写的内容并对此进行思考。

祝你有个好的一天！

于 2008-10-17T22:45:17.740 回答
-1

我同意你的看法——我采取了一种不同的方法，我在许多公司环境中都看到了这种方法：

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

此外，此命名有助于您在加入时跟踪列来自的表。

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

于 2008-10-17T22:32:57.297 回答