数据库、表和列命名约定？

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

想要改进这个问题？更新问题，以便可以通过编辑这篇文章用事实和引文来回答它。

10 年前已关闭。

Answer 1

基本数据库命名约定（和样式）（点击这里有更详细的描述）

表名
选择简短、明确的名称，最多使用一两个单词
轻松区分表格
方便命名唯一的字段名称以及查找和链接表
给表命名为单数，而不是复数（更新：我仍然同意这个约定的原因，但大多数人真的喜欢复数表名，所以我软化了我的立场）...请点击上面的链接

Answer 2

表名单数。 假设您正在对某人与其地址之间的关系进行建模。
例如，如果您正在阅读数据模型，您会更喜欢
“每个人可能住在 0,1 个或多个地址。” 或者
“每个人可能住在 0,1 个或多个地址。”
我认为使用复数称呼更容易，而不是必须将人改写为人。 另外，集体名词通常与单数名词不同。

Answer 3

表名称：它应该是单数，因为它是代表现实世界对象的单数实体，而不是单数的对象。

列名：它应该是单数，只有这样它才能表达它将持有原子值并符合规范化理论。 然而，如果有n个相同类型的属性，那么它们应该以1、2、...、n等为后缀。

给表/列添加前缀：这是一个很大的话题，稍后会讨论。

大小写：应该是 Camel 大小写

我的朋友，Patrick Karcher，我请求您不要写任何可能冒犯某人的内容，正如您所写的，“•此外，外键的命名必须与殴打不这样做的人应该是合法的。” 我的朋友帕特里克我从来没有犯过这个错误，但我写得一般。 如果他们一起计划为此击败你怎么办？ :)

Answer 4

1. 不可以。表应该以其代表的实体命名。
   指的是其中一项记录所代表的人，而不是人。
2. 再说一遍，同样的事情。 FirstName 列确实不应该称为 FirstNames。 这完全取决于您想用列表示什么。
3. 不。
4. 是的。 为了清楚起见，将其案例化。 如果您需要像“FirstName”这样的列，则使用大小写将使之更易于阅读。

好的。 那是我的 0.02 美元

Answer 5

--Example SQL

CREATE TABLE D001_Students
(
    StudentID INTEGER CONSTRAINT nnD001_STID NOT NULL,
    ChristianName NVARCHAR(255) CONSTRAINT nnD001_CHNA NOT NULL,
    Surname NVARCHAR(255) CONSTRAINT nnD001_SURN NOT NULL,
    CONSTRAINT pkD001 PRIMARY KEY(StudentID)
);

CREATE INDEX idxD001_STID on D001_Students;

CREATE TABLE D002_Classes
(
    ClassID INTEGER CONSTRAINT nnD002_CLID NOT NULL,
    StudentID INTEGER CONSTRAINT nnD002_STID NOT NULL,
    ClassName NVARCHAR(255) CONSTRAINT nnD002_CLNA NOT NULL,
    CONSTRAINT pkD001 PRIMARY KEY(ClassID, StudentID),
    CONSTRAINT fkD001_STID FOREIGN KEY(StudentID) 
        REFERENCES D001_Students(StudentID)
);

CREATE INDEX idxD002_CLID on D002_Classes;

CREATE VIEW V001_StudentClasses
(
    SELECT
        D001.ChristianName,
        D001.Surname,
        D002.ClassName
    FROM
        D001_Students D001
            INNER JOIN
        D002_Classes D002
            ON
        D001.StudentID = D002.StudentID
);

这些是我学到的约定，但您应该适应您开发软管使用的任何内容。

1. 复数。 它是实体的集合。
2. 是的。 属性是实体的单一属性的表示。
3. 是的，前缀表名允许轻松跟踪所有约束索引和表别名的命名。
4. 表名和列名采用帕斯卡大小写，索引和约束采用前缀 + 全部大写。

Answer 6

这是提供一些选择的链接。 我正在寻找一个可以遵循的简单规范，而不必依赖于部分定义的规范。

http://justinsomnia.org/writings/naming_conventions.html

Answer 7

我们的偏好：

1. 表名应该是复数吗？
   绝不。 认为它是一个集合的论点是有道理的，但你永远不知道表将包含什么（0,1 或许多项目）。 复数规则使命名变得不必要的复杂。 1 栋房子，2 栋房子，老鼠对老鼠，人对人，我们甚至没有看过任何其他语言。

   更新人员集属性 = 'value' 作用于表中的每个人员。
   Select * from person where person.name = 'Greg' 返回人员行的集合/行集。

2. 列名应该是单数吗？
   通常是的，除非您违反规范化规则。

3. 我应该为表或列添加前缀吗？
   主要是平台偏好。 我们更喜欢在列前加上表名作为前缀。 我们不为表添加前缀，但为视图 (v_) 和存储过程（sp_ 或 f_（函数））添加前缀。 这可以帮助那些想要尝试更新 v_person.age 的人，它实际上是视图中的计算字段（无论如何都无法更新）。

   这也是避免关键字冲突的好方法（delivery.from 会中断，但 payment_from 不会）。

   它确实使代码更加冗长，但通常有助于提高可读性。

   bob = new person()
bob.person_name = '鲍勃'
bob.person_dob = '1958-12-21'
   ...非常易读且明确。 但这可能会失控：

   customer.customer_customer_type_id

   表示 customer 和 customer_type 表之间的关系，表示 customer_type 表 (customer_type_id) 上的主键，如果您在调试查询时看到“customer_customer_type_id”，您会立即知道它来自哪里（客户表）。< /p>

   或者您在 customer_type 和 customer_category 之间存在 MM 关系（仅某些类型适用于某些类别）

   customer_category_customer_type_id

   ...有点长（！）。

4. 我应该在命名项目时使用大小写吗？
   是 - 小写:)，带下划线。 这些都是非常可读且跨平台的。 结合上面的3点也是有道理的。

   不过，其中大部分都是偏好。 - 只要保持一致，任何必须阅读它的人都应该是可预测的。

Answer 8

查看 ISO 11179-5：命名和标识原则
您可以在这里获取：http://metadata-standards.org/11179/#11179-5

我不久前在博客上写过它：ISO- 11179 命名约定

Answer 9

我认为：

1. 表名应该是复数。
2. 列名应该是单数。
3. 不可以。
4. 表名和列名都可以使用驼峰命名法（我的首选）或下划线分隔符。

然而，正如已经提到的，任何约定都比没有约定好。 无论您选择如何执行，都将其记录下来，以便将来的修改遵循相同的约定。

Answer 10

我在一个拥有三名 DBA 的数据库支持团队工作，我们考虑的选项是：

1. 任何命名标准都比没有标准好。
2. 没有“唯一正确”的标准，我们都有自己的偏好。
3. 如果已有标准，请使用它。 不要创建另一个标准或混淆现有标准。

我们对表使用单数名称。 表往往以系统名称（或其缩写）为前缀。 如果系统复杂，这非常有用，因为您可以更改前缀以将表逻辑分组在一起（即 reg_customer、reg_booking 和 regadmin_limits）。

对于字段，我们希望字段名称包含表的前缀/缩写（即 cust_address1），并且我们也更喜欢使用一组标准后缀（_id 表示 PK，_cd 表示“code”，_nm 表示“name” "，_nb 表示“数字”，_dt 表示“日期”）。

外键字段的名称应与主键字段的名称相同。

即，

SELECT cust_nm, cust_add1, booking_dt
FROM reg_customer
INNER JOIN reg_booking
ON reg_customer.cust_id = reg_booking.cust_id

在开发新项目时，我建议您写出所有首选实体名称、前缀和首字母缩略词，并将此文档提供给您的开发人员。 然后，当他们决定创建新表时，他们可以参考文档，而不是“猜测”表和字段应该被称为什么。

Answer 11

好吧，既然我们正在权衡意见：

我认为表名应该是复数。 表是实体的集合（表）。 每行代表一个实体，表代表集合。 因此，我将把 Person 实体表称为 People（或 Person，无论您喜欢什么）。

对于那些喜欢在查询中看到单数“实体名称”的人，这就是我使用表别名的原因：

SELECT person.Name
FROM People person

有点像 LINQ 的“from person in people select person.Name”。

至于2、3和4，我同意@Lars。

Answer 12

聚会已经很晚了，但我仍然想添加关于列前缀的两分钱 对于

使用列的 table_column （或 tableColumn）命名标准似乎有两个主要论点，两者都基于列名本身是唯一的事实在整个数据库中：

1）您不必一直在查询中指定表名和/或列别名

2）您可以轻松地在整个代码中搜索列名

我认为这两个参数都有缺陷。 不使用前缀解决这两个问题的方法很简单。 这是我的建议：

始终在 SQL 中使用表名。 例如，始终使用 table.column 而不是 column。

它显然解决了 2)，因为您现在只需搜索 table.column 而不是 table_column。

但我能听到你尖叫，这怎么解决1）？ 这正是为了避免这种情况。 是的，确实如此，但该解决方案存在严重缺陷。 为什么？ 好吧，前缀解决方案归结为：
为了避免在出现歧义时必须指定 table.column，您可以将所有列命名为 table_column！
但这意味着从现在起您每次指定列时都必须写入列名。 但如果你无论如何都必须这样做，那么与总是显式编写 table.column 相比，有什么好处呢？ 确切地说，没有任何好处，输入的字符数完全相同。

编辑：是的，我知道用前缀命名列会强制执行正确的用法，而我的方法依赖于程序员

Answer 13

我知道这已经晚了，而且这个问题已经得到了很好的回答，但我想就列名前缀的#3 提出我的意见。

所有列都应使用定义它们的表唯一的前缀命名。

例如，给定表“customer”和“address”，让我们使用前缀“cust”和“addr”，分别。 “customer”中将包含“cust_id”、“cust_name”等。 “地址”将包含“addr_id”、“addr_cust_id”（FK 返回给客户）、“addr_street”等。

当我第一次看到这个标准时，我坚决反对它。 我讨厌这个主意。 我无法忍受所有额外的打字和冗余的想法。 现在我已经有了足够的经验，我再也不会回去了。

这样做的结果是数据库模式中的所有列都是唯一的。 这样做有一个主要好处，它胜过了所有反对它的论点（当然，在我看来）：

您可以搜索整个代码库并可靠地找到涉及特定列的每一行代码。

#1 的好处是非常巨大的。 我可以弃用某个列，并确切地知道需要更新哪些文件，然后才能安全地从架构中删除该列。 我可以更改列的含义并确切地知道哪些代码需要重构。 或者我可以简单地判断列中的数据是否正在系统的特定部分中使用。 我无法计算有多少次这将一个潜在的庞大项目变成了一个简单的项目，也无法计算我们在开发工作中节省了多少时间。

另一个相对较小的好处是，在进行自连接时只需使用表别名：

SELECT cust_id, cust_name, addr_street, addr_city, addr_state
    FROM customer
        INNER JOIN address ON addr_cust_id = cust_id
    WHERE cust_name LIKE 'J%';

Answer 14

我对此的看法是：

1）不，表名应该是单数。

虽然它对于简单选择（select * from Orders）似乎有意义，但对于 OO 等效项（Orders x = new Orders）意义不大。

数据库中的表实际上是该实体的集合，一旦您使用集合逻辑，它就更有意义：

select Orders.*
from Orders inner join Products
    on Orders.Key = Products.Key

最后一行（连接的实际逻辑）看起来与复数表名称混淆。

我不确定总是使用别名（正如马特建议的那样）可以解决这个问题。

2) 它们应该是单数，因为它们只包含 1 个属性

3) 决不，如果列名不明确（如上所述，它们都有一个名为 [Key] 的列），表的名称（或其别名）可以很好地区分它们足够的。 您希望查询能够快速输入且简单 - 前缀会增加不必要的复杂性。

4）无论你想要什么，我建议使用大写字母

我认为对于这些都没有一套绝对的指导方针。

只要您选择的内容在应用程序或数据库中保持一致，我认为这并不重要。

Answer 15

我认为这些问题的最佳答案将由您和您的团队给出。 拥有一个命名约定比命名约定的精确程度要重要得多。

由于没有正确的答案，您应该花一些时间（但不要太多）并选择自己的约定 - 这是重要的部分 - 坚持下去。

当然，最好寻求一些有关标准的信息，这就是您所要求的，但不要担心或担心您可能得到的不同答案的数量：选择一个看起来更适合您的答案。

以防万一，我的回答是：

1. 是的。 表是一组记录、教师或演员，所以……复数。
2. 是的。
3. 我不使用它们。
4. 我更经常使用的数据库 - Firebird - 将所有内容保留为大写，所以这并不重要。 不管怎样，当我编程时，我会以更容易阅读的方式编写名称，例如releaseYear。

Answer 16

SELECT 
   UserID, FirstName, MiddleInitial, LastName
FROM Users
ORDER BY LastName

Answer 17

我经常听到这样的争论：表是否复数完全取决于个人喜好，并且没有最佳实践。 我不相信这是真的，尤其是作为一名程序员而不是 DBA。 据我所知，除了“这对我来说有意义，因为它是对象的集合”之外，没有任何合理的理由将表名复数，而使用单数表名可以在代码中获得合法的收益。 例如：

1. 它避免了由复数歧义引起的错误和错误。 程序员并不以其拼写专业知识而闻名，并且某些单词的复数形式令人困惑。 例如，复数单词是以“es”结尾还是仅以“s”结尾？ 是人还是人？ 当您与大型团队一起处理项目时，这可能会成为一个问题。 例如，团队成员使用不正确的方法对其创建的表进行复数化的实例。 当我与该表交互时，它已在我无法访问或需要很长时间才能修复的代码中使用。 结果是我每次使用该表时都必须记住将其拼写错误。 与此非常相似的事情发生在我身上。 您越能让团队的每个成员一致、轻松地使用准确、正确的表名称，而不会出现错误，也不必一直查找表名称，那就越好。 单数版本在团队环境中更容易处理。

2. 如果您使用表名的单数版本并在主键前添加表名前缀，那么您现在可以轻松地通过代码从主键确定表名，反之亦然。 您可以得到一个带有表名的变量，将“Id”连接到末尾，现在您可以通过代码获得表的主键，而无需执行额外的查询。 或者，您可以从主键末尾截去“Id”，以通过代码确定表名。 如果您使用“id”而没有主键的表名称，则无法通过代码从主键确定表名称。 此外，大多数使用复数表名并在 PK 列前加上表名的人在 PK 中使用表名的单数版本（例如 statuses 和 status_id），因此根本不可能做到这一点。

3. 如果将表名称设置为单数，则可以让它们与它们代表的类名称相匹配。 再一次，这可以简化代码并允许您做一些非常巧妙的事情，例如只用表名来实例化一个类。 它还只会使您的代码更加一致，从而导致...

4. 如果您将表名称设为单数，它会使您的命名方案一致、有组织且易于在每个位置维护。 您知道，在代码中的每个实例中，无论是在列名称中、作为类名称还是作为表名称，它都是完全相同的名称。 这使您可以进行全局搜索以查看使用数据的所有位置。 当您使用复数形式的表名称时，有时您将使用该表名称的单数版本（它在主键中变成的类）。 在某些情况下，您的数据不会被称为复数，而在某些情况下，数据会被称为单数，这是有意义的。

总而言之，如果您使用复数形式的表名称，您将失去使代码更智能、更易于处理的各种优势。 甚至在某些情况下，您必须使用查找表/数组将表名转换为您可以避免的对象或本地代码名称。 单一表名虽然一开始可能感觉有点奇怪，但与复数名称相比具有显着的优势，我相信这是最佳实践。

Answer 18

表名应始终是单数，因为它们代表一组对象。 正如你所说的“牧群”是指一群羊，或者“羊群”是指一群鸟。 不需要复数。 当表名由两个名称组成并且命名约定为复数时，很难知道复数名称应该是第一个单词还是第二个单词还是两者。
这是逻辑——Object.instance，而不是objects.instance。 或 TableName.column，而不是 TableNames.column。
Microsoft SQL 不区分大小写，当表名或列名由两个或多个名称组成时，如果使用大写字母，则更容易读取表名或列名。

Answer 19

这里迟到的答案，但简而言之：

1. 复数表名称：我的偏好是复数
2. 单数列名称：是
3. 前缀表或列：

• 表：*通常*没有前缀是最好的。
• 列：否。

4. 命名项目时使用任意大小写：表和列均采用 PascalCase。

详细说明：

(1)你必须做的事情。很少有事情你必须每次都以某种方式做，但是有一些。

• 使用“[singularOfTableName]ID”格式命名您的主键。 也就是说，无论您的表名称是 Customer 还是 Customers，主键都应该是 CustomerID。
• 此外，不同表中的外键必须命名一致。 殴打不这样做的人应该是合法的。 我认为，虽然定义的外键约束通常很重要，但一致的外键命名始终很重要。
• 您的数据库必须具有内部约定。 尽管在后面的部分中您会看到我非常灵活，但数据库内的命名必须非常一致。 您的客户表是称为“Customers”还是“Customer”并不重要，重要的是您在同一数据库中以相同的方式执行此操作。 您可以抛硬币来决定如何使用下划线，但是您必须继续以相同的方式使用它们。 如果你不这样做，你就是一个应该低自尊的坏人。

(2) 您可能应该做什么。

• 不同表上表示相同类型数据的字段应该命名相同。 不要在一张桌子上有 Zip，而在另一张桌子上有 ZipCode。
• 要分隔表名或列名中的单词，请使用 PascalCasing。 使用驼峰命名法本质上不会有问题，但这不是惯例，而且看起来很有趣。 稍后我将讨论下划线。 （您不能像以前那样使用 ALLCAPS。OBNOXIOUSTABLE.ANNOYING_COLUMN 在 20 年前的 DB2 中还可以，但现在不行。）
• 不要人为地缩短或缩写单词。 名字长而清晰比短而混乱要好。 超短名字是黑暗、野蛮时代的产物。 Cus_AddRef。 那到底是什么？ 保管收件人参考资料？ 客户额外退款？ 自定义地址推荐？

(3) 你应该考虑什么。

• 我真的认为你应该为表使用复数名称； 有些人认为单一。 阅读其他地方的论点。 但是，列名称应该是单数。 即使您使用复数表名称，表示其他表组合的表也可能是单数。 例如，如果您有一个 Promotions 和一个 Items 表，则表示属于促销活动的商品的表可以是 Promotions_Items，但也可以合法地是 Promotion_Items I think（反映一对多关系）。
• 出于特定目的一致使用下划线。 使用 PascalCasing，只是通用表名称应该足够清晰； 您不需要下划线来分隔单词。 保存下划线（a）表示关联表或（b）表示前缀，我将在下一个项目符号中解决。
• 前缀既不好也不坏。 通常并不是最好的。 在您的第一个或两个数据库中，我不建议使用前缀对表进行一般主题分组。 表格最终无法轻松适合您的类别，并且实际上会使查找表格更加困难。 凭借经验，您可以规划并应用利大于弊的前缀方案。 我曾经在数据库中工作过，其中数据表以 tbl 开头，配置表以 ctbl 开头，视图以 vew 开头，过程的 sp em> 和 udf 的 fn 以及其他一些； 它经过精心、一致的应用，所以效果还不错。 唯一需要前缀的时候是当您有真正独立的解决方案，并且由于某种原因驻留在同一个数据库中时； 为它们添加前缀对于对表进行分组非常有帮助。 对于特殊情况，例如您想要脱颖而出的临时表，前缀也是可以的。
• 你很少（如果有的话）会想要
  为列添加前缀。

Answer 20

我建议查看 Microsoft 的 SQL Server 示例数据库：
https://github.com/Microsoft/sql-server-samples/releases /tag/adventureworks

AdventureWorks 示例使用非常清晰且一致的命名约定，该约定使用架构名称来组织数据库对象。

1. 表的单数名称
2. 列的单数名称 表
3. 前缀的模式名称（例如：SchemeName.TableName）
4. Pascal 大小写（又名大驼峰式大小写）

Answer 21

1. 绝对保持表名单数，是人而不是人
2. 这里也一样
3. 没有。 我见过一些可怕的前缀，甚至说明我们正在处理的是表（tbl_）或用户存储过程（usp_）。 接下来是数据库名称...不要这样做！
4. 是的。 我倾向于将所有表名都采用 PascalCase

Answer 22

命名约定允许开发团队在项目的核心设计可发现性和可维护性。

良好的命名约定需要时间来发展，但一旦到位，团队就可以使用共同语言继续前进。 良好的命名约定会随着项目的发展而有机地发展。 良好的命名约定可以轻松应对软件生命周期中最长且最重要的阶段（生产中的服务管理）期间的变化。

以下是我的回答：

1. 是的，当表名称引用一组交易、证券或交易对手时，表名应该是复数。
2. 是的。
3. 是的。 SQL 表以 tb_ 为前缀，视图以 vw_ 为前缀，存储过程以 usp_ 为前缀，触发器以 tg_ 为前缀，后跟数据库名称。
4. 列名称应为小写，并用下划线分隔。

命名很困难，但在每个组织中都有一个人可以命名事物，并且在每个软件团队中都应该有一个人负责命名标准并确保像 sec_id、sec_value 这样的命名问题em> 和 security_id 在融入项目之前就得到了解决。

那么良好的命名约定和标准的基本原则是什么： -

• 使用客户的语言和
  您的解决方案领域
• 具有描述性
• 保持一致
• 消除歧义、反映和重构
• 不要使用缩写，除非它们
  大家都清楚
• 不要使用 SQL 保留关键字作为
  列名

Answer 23

我也赞成 ISO/IEC 11179 风格的命名约定，并指出它们是指导方针而不是规定性的。

请参阅维基百科上的数据元素名称：

“表是实体的集合，并遵循集合命名准则。理想情况下，使用集体名称：例如，Personnel 也是正确的：Employees 不正确的名称包括：Employee、tblEmployee 和 EmployeeTable。

与往常一样，规则也有例外，例如，总是只有一行的表可能最好使用单一名称，例如配置表。 一致性至关重要：检查您的购物是否有惯例，如果有，请遵守； 如果你不喜欢它，那就做一个商业案例来改变它，而不是成为独行侠。