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

我曾经这样在数据库中标记列：

user_id
user_name
user_password_hash

为了避免在连接两个表时发生冲突，但是后来我学到了更多关于如何别名表的知识，于是我停止这样做。

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

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

我建议您采用一种更自然的方法。

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

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

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

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

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

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

我认为，在数据库模式中，每列在表之间应具有唯一的名称。这有几个原因：

• 从建模的角度来看：首先从大量的属性开始，然后将其规范化为表格。随着时间的流逝，您可能会进一步规范化或规范化，或者引入视图或实例化视图，或者引入新表。如果所有列名都是唯一的，这将永远不是问题。

• 您可以使用以下连接语法：a JOIN b USING (a_id) JOIN c USING (a_id)。非常方便，并有助于以下几点。

• 如果您运行带有大量联接的查询或使用创建查询SELECT *，则您永远不会（或者可能很少）发生冲突。想想加盟person.name，product.name，country.name，等Urgh。

• 通常，如果您有大量查询，则很难跟踪id到处都意味着什么。

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

USERS
----
id
username,
password
registration_date

我使用大写的表名。这使我可以轻松识别表格。我刚刚命名的列各代表其含义。我尽量不要使用数字或在其中包含任何前缀或后缀。这将使查询完全简单且非常简单。

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

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

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

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

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

一些观察：

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

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

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

名字，姓氏等。

对于Oracle，您将不需要命名列“ id”或“ name”或任何通用名称。

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

但是，即使您不使用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个字符，但是我从不在乎。

...

除此以外：

• 列始终为单数（表始终为复数）
• 所有名称均为小写，以防万一区分大小写
• 由于上述原因，请使用下划线代替驼峰式大小写。

更新：对于不熟悉Oracle 联接行为的人员，请参阅“ 精通Oracle SQL：联接条件”的最后一个示例，其中提到：

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

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

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

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

   SELECT *
   FROM employee
   INNER JOIN department
     USING (department_id);
   
     -- compare to
     ON employee.department_id = department.department_id;