在数据库中标记列的有效方法是什么？

user_id
user_name
user_password_hash

#1 楼

在您的情况下，前缀用户是多余的。我们（负责开发的人）知道这是表用户，所以为什么在每个字段前面添加user_前缀？

我建议您使用一种更自然的方法来做到这一点。

一个人的特征是什么：姓氏，名字，生日，国籍等...

汽车的特征是什么：型号，年份，颜色，能量等...

您的列应命名为尽可能自然的名称，这将使每个人，您和您之后的人的架构都更加清晰。这也称为维护阶段，您可以做的任何使维护变得容易的事情通常都是值得的。

#2 楼

除了Spredzy的注释之外，您还可以将主键标记为相同的ID（ID），以便在即时编写查询时，您可以轻松地调用（u.ID = c.ID），而不必查找“ Was it countryID” ，country_ID，国家/地区ID，国家/地区ID 、?“

#3 楼

我完全同意戴维·霍尔（David Hall）对Spredzy出色回答的补遗。简单自然是您要走的路。如果您也自然地命名表，那么表混乱就不会成为问题。

如果您可以拥有users.id和cars.id，则没有users.user_id和cars.car_id

#4 楼

我认为在数据库模式中，每列在表之间应具有唯一的名称。造成这种情况的原因有很多：从建模的角度来看：从大量的属性开始，然后将其规范化为表格。随着时间的流逝，您可能会进一步规范化或规范化，或者引入视图或实例化视图，或者引入新表。如果所有列名都是唯一的，这将永远不是问题。
您可以使用以下连接语法：a JOIN b USING (a_id) JOIN c USING (a_id)。非常方便，还可以帮助您解决以下问题。
如果运行带有大量联接的查询或使用SELECT *创建物化视图，则您永远不会（或者可能很少）发生冲突。考虑加入person.name，product.name，country.name等。Urgh。
通常，如果您有很大的疑问，则很难跟踪id在任何地方的含义。

#5 楼

让我们来看一下您的示例，它看起来像这样：

USERS
----
id
username,
password
registration_date

我使用大写的表名。这使我可以轻松识别表格。我刚刚命名的列各代表其含义。我尽量不要使用数字或不使用任何前缀或后缀。这将使查询变得简单而直接。

顺便说一句，我认为您应该找到自己喜欢的样式并坚持使用。如果您经常更改它，那么您将拥有一个更混乱的数据库架构。

#6 楼

像其他人一样，我建议您不要在表中包括表名。除非您有成百上千个具有几乎相同的列名的表：如果您有数十个表都具有一个标题为ID的列，则务必以表名作为前缀。

我最近离开了一家公司，其中一位开发人员更喜欢在主键和外键列前加上pk和fk。这导致某些令人讨厌的情况，其中列以pkfk开头（通常是基于2列的复合主键，其中一列是另一张表的外键）。

#7 楼

我正在一个环境中工作，其中每个列名都以从表名派生的前缀开头，这不是我的发明，但是我对此很满意。

理想情况下，列名在整个过程中都是唯一的数据库中的所有表。

一些观察结果：


我们只需要表别名，当表在select语句中多次连接时
防止在复制代码段时出现一些错误，因为列名必须适合表名
它有助于显示外键列指向哪个表

一般思想：
大多数重要的是每种命名约定的一致性：
-单数与复数（适用于表而不是列）
-标识主键和外键（它们建立结构与数据库内容的关系）
-存储字符串和相同字符串的简短变体时要保持一致
-与标志，状态等保持一致。

#8 楼

我同意Spredzy的回答，但会补充一点，作为优先事项，我将使用camelCase而不是under_score。

firstName，lastName等。

#9 楼

对于Oracle，您不希望将列名命名为'id'或'name'或任何通用名称。

问题在于，默认情况下，在较早版本中，Oracle将尝试基于在相似的列名上，因此，如果我对所有名称都进行了正确命名，那么我还最终在表之间指定了默认的join子句。

但是即使您没有使用Oracle，也不会选择出现在多个表中的名称，这也意味着您不必每次都要在两个表中进行选择时就不必经历别名的麻烦：

SELECT
  instrument.name as instrument_name,
  instrument.abbr as instrument_abbr,
  source.name     as source_name,
  source.abbr     as source_abbr,
  ...
FROM ...

因此，如果多表选择是常态，则较长的列名可以节省您的键入时间。 （如果您一次只使用一个表……您真的需要一个关系数据库吗？）

...并且保存类型使我们在Oracle中遇到另一个问题-至少在8i中（我上Oracle SQL调优和数据建模课程时的当前版本），执行计划的缓存仅基于查询的前几个字符（不记得确切的值... 1024？），因此如果您的查询在where子句的末尾仅因所有方式而有所不同，并且要提取的列很长，则可能会导致性能下降，因为它无法正确缓存执行计划。

Oracle有一个指南来选择他们认为是好的表和列名的指南，这基本上是删除字母的指南，直到大约5到8个字符，但我从不在乎。 br />
...

除此之外，


列总是单数（表总是复数）
所有名称均为小写，仅在cas中如果由于上述原因导致区分大小写
，请使用下划线代替驼峰式大小写。

update：对于不熟悉Oracle联接行为的用户，请参见精通Oracle的最后一个示例SQL：联接条件，其中提到：


发生了什么？原因在于，除了vendor_id之外，这两个表还有另一对具有相同名称的列。该列是名称。因此，当您要求在供应商表和零件表之间进行自然联接时，联接不仅通过将两个表的Supplier_id列相等，而且也将两个表中的name列相等而发生。由于没有供应商名称与该供应商的零件名称相同，因此查询不会返回任何行。


在“旧连接语法”（8i及更早版本）下，“ “自然联接”是默认的联接行为，如果您未指定联接条件，我相信仍然如此。一旦“ NATURAL JOIN”成为9i中的正式选项，一般建议不要使用它，因为糟糕的列命名会把您搞砸，这是我要提倡的好列名称。

#10 楼

切勿使用双引号"，因为这样做会覆盖数据库的本机大小写折叠。 SQL规范要求将所有标识符都折叠为大写。某些数据库（例如PostgreSQL）将它们折叠为小写形式。如果不加引号，则它将在所有数据库中都可用，并且它们可以将它们折叠为规范或特定于rdbms的默认值。
请使用under_score（_），因为如上所述，您不应该使用camelCase 。

将{entity}_id用于ID（以及指向这些ID的外键）。因为那样您可以使用USING子句。连接条件中使用的全局唯一键名是规范中建立的约定。

SELECT *
FROM employee
INNER JOIN department
  USING (department_id);

  -- compare to
  ON employee.department_id = department.department_id;