当涉及到数据库列时，您更喜欢冗长的命名吗？ [关闭]

Question

你的偏好是什么？

假设我们有一个通用的 Product 表，它有一个 ID、一个名称和一个对类别的外键引用。您希望将您的表命名为：

CREATE TABLE Products
(
    ProductID int NOT NULL IDENTITY(1,1) PRIMARY KEY,
    CategoryID int NOT NULL FOREIGN KEY REFERENCES Categories(CategoryID),
    ProductName varchar(200) NOT NULL
)

对列使用显式命名（例如，ProductName、ProductID）或类似的名称：

CREATE TABLE Products
(
    ID int NOT NULL IDENTITY(1,1) PRIMARY KEY,
    CategoryID int NOT NULL FOREIGN KEY REFERENCES Categories(ID),
    Name varchar(200) NOT NULL
)

据我所见，.NET 世界的惯例是明确的——示例倾向于使用第一个示例，而开源和 RoR 世界倾向于使用第二个示例。就我个人而言，乍一看，我发现第一个更容易阅读和理解：select p.ProductID, p.ProductName, c.CategoryName from Categories c inner join Products p on c.CategoryID = p.CategoryID 对我来说似乎比 select p.ID AS ProductID, p.Name AS ProductName, c.Name AS CategoryName from Categories c inner join Products p on c.ID = p.CategoryID 更自然

我想鉴于我提供的基本示例，这没什么大不了的，但是当您处理大量数据和表格时呢？我仍然会发现第一个示例比第二个更好，尽管可能两者的某种组合可能值得研究（<Table>ID 用于 ID，但仅Name 用于名称？）。显然，在现有项目上，您应该遵循已经建立的约定，但是对于新的开发呢？

你的喜好是什么？

Answer 1

表名已经给出了上下文。 无需在列名前加上它。 连接表时使用 table.column 语法。

Answer 2

我是选项 3 的粉丝：

CREATE TABLE Products
(
    ProductId int NOT NULL IDENTITY(1,1) PRIMARY KEY,
    CategoryId int NOT NULL FOREIGN KEY REFERENCES Categories(CategoryId),
    Name varchar(200) NOT NULL
)

所以主键是获得表名作为前缀的唯一列——恕我直言，它可以更容易地查看连接何时出错。再说一次，如果将来有可能不得不处理合并复制情况，我也喜欢将 GUID 用于主键...

Answer 3

查看相关问题：Is prefixing each field name in a table with abbreviated table name a good practice?

作为I mentioned in my answer;用表名作为字段名前缀的概念来自旧系统的旧时代，当时整个数据库中的每个字段都需要是唯一的。现代系统不再需要这一点，因此它只是一个不再需要的约定。正如Think Before Coding所提到的“表名已经给出了上下文。不需要在列名前面加上前缀”

Answer 4

我坚持使用尽可能短的名称。人们在每一列上加上表名的前缀让我很暴力。 PERSON.first_name，而不是 PERSON.person_first_name。我们知道它是一个人，它在 person 表中......它还会是什么？

我唯一违反此规则的地方是 id 列，例如：PERSON.personID。

规则是，向爱因斯坦道歉；尽可能详细，但不要更详细。

Answer 5

我通常给每个表一个唯一的前缀。所以你的例子就像

CREATE TABLE Products
(
    PROD_ID int NOT NULL IDENTITY(1,1) PRIMARY KEY,
    PROD_CAT_ID int NOT NULL FOREIGN KEY REFERENCES Categories(CAT_ID),
    PROD_NAME varchar(200) NOT NULL
)

这使得加入和选择列更容易，因为您没有名称冲突。除非您多次引用同一个表，否则您甚至不需要表名别名（很可能）。

但是最近我开始认为 (2) 可能会更好，因为它更接近我在编写代码时使用的命名约定（在我的例子中是 C#）。

Answer 6

当您有很多连接时，ID 会非常混乱。我更喜欢明确的 id 名称与外键中的 id 名称相匹配。这样，您始终知道 customerid 将与 customerid 加入任何其他具有该列的表中。

永远不要使用名称作为字段名称。这是一个保留字，因此应避免使用。数据库以某种方式使用保留的关键字，将它们也用作字段名称只是一种糟糕的做法，并且比从一开始就使用正确的描述性名称会产生更多的错误。

Answer 7

一种观点认为，列名应该代表数据库中的单个域空间。例如，产品名称与公司名称完全不同。一个可能比另一个长，等等。在这方面，您应该使用第一种方法，因为它可以区分两者。

另一方面，我在某种程度上同意 Think Before Coding 的逻辑。我总是使用 table.column 语法，所以上下文应该清楚。

使用更详细的列名通常可以避免与保留字发生冲突。

再一次，如果您的产品表中的每一列都是 ProductXxxx，这可能是非常多余的。

换句话说，我没有绝对的偏好，但我确实更倾向于冗长的命名约定。

Answer 8

我更喜欢使用“ID”的简短版本。这是一个易于理解和遵循的约定，表的记录标识符将被称为“ID”，它将引用其“自己的”表而不是其他东西（尽管有时不需要“自己的”标识符）一些表，如映射）。

它给出的另一个结果是，无论何时编写查询，您都不需要思考和记住确切的列名。您知道，只要表具有记录标识符就可以由“ID”引用。

它简化了事情。

Answer 9

我更喜欢uid、gid、pid、wid、lid等。

Answer 10

我认为如果列名在数据库中不是唯一的，你应该在它前面加上表名。比如，ProductId，ProductName。对于与其他表中的列不冲突的列，不要为其添加前缀。

Answer 11

选项 2 是最好的（当然对我来说 :)），
我是一名 PHP 程序员而不是 .NET 程序员。

Answer 12

我更喜欢第二种选择，因为第一种选择对我来说似乎是不必要的重复。当然，我主要是一名 Ruby on Rails 程序员，所以我喜欢DRY principle。 :) 我发现 C# 编程很烦人，因为一切都使用第一个、明确但重复的版本。