数据库、表和列的命名约定？ [关闭]答案

【问题标题】：Database, Table and Column Naming Conventions? [closed]数据库、表和列的命名约定？ [关闭]
【发布时间】：2010-09-05 16:18:04
【问题描述】：

每当我设计数据库时，我总是想知道是否有最好的方法来命名我的数据库中的项目。我经常问自己以下问题：

表名应该是复数吗？
列名应该是单数吗？
我应该为表或列添加前缀吗？
我应该在命名项目时使用任何大小写吗？

对于数据库中的项目命名是否有任何推荐的准则？

【问题讨论】：

我认为我们应该将表命名为复数，将列命名为单数。
我将表格视为包含多个项目的“存储”，而不是单个“实体”，因此我将其命名为复数。当我将表映射到对象时，我会将对象命名为单数。这只是我个人的看法。
@Tryinko 在所有地方使用 ID 对于任何连接多个表的人来说都是地狱。知道这一点是 PK 的微小优势不可能超过在每个血腥查询中一遍又一遍地重新为 dang ID 列重新别名的令人难以置信的烦恼。如果您想要一种在表格中表示 PK 的方法，请将其设为第一列。此外，在我看来，在列名称中表示 FK 是另一种非常邪恶的反模式。
看看this Answer。
关于大小写，我建议使用snake_case，因此您不必担心首字母缩略词的大小写，就像PascalCase 一样。例如：PHPVersion 还是 PhpVersion？在蛇的情况下，它显然是 php_version 等。

标签： database database-design language-agnostic naming-conventions

【解决方案1】：

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

复数表名：我的偏好是复数
单列名称：是
为表格或列添加前缀：

表格：*通常*最好没有前缀。
列：没有。

在命名项目时使用任何大小写： PascalCase 用于表和列。

阐述：

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

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

(2) 你应该怎么做。

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

(3) 你应该考虑什么。

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

【讨论】：

"表示不同表中相同类型数据的字段应命名相同。不要在一个表上使用 Zip，在另一个表上使用 ZipCode。"是的，是的，一百万次是的。你能说我们的数据库不是这样设计的吗？一个personid 可能以十几种不同的方式中的任何一种来引用，维护起来非常烦人。在我可以控制设计的任何数据库中，我始终遵守这条规则，它让生活变得更加简单。
我认为主键应该只是“ID”。这样一个简单的约定使主键可预测且可快速识别。但是，当它在其他表中用作外键时，我会在表名（“PersonID”）之前添加它。这种约定有助于区分同一个表中的主键和外键。
@Tryinko 到处使用 ID 对于任何连接多个表的人来说都是地狱。知道这一点是 PK 的微小优势不可能超过在每个血腥查询中一遍又一遍地重新为 dang ID 列重新别名的令人难以置信的烦恼。如果您想要一种在表格中表示 PK 的方法，请将其设为第一列。此外，在我看来，在列名称中表示 FK 是另一种非常邪恶的反模式。
@Triynko 如果您只使用“ID”，则在编程上也无法确定它所属的表。有了表名前缀，你就可以简单的把主键的最后两位截掉，通过代码知道它所属的表名。很多时候，IT 和 DBA 人员没有意识到程序员在以某些方式设计数据库时具有编码优势。
@ErikE 我的意思是你不知道CustomerID 是Customer 表中的主键，还是其他表中的外键。这是一个小问题。为什么要使用像c 这样的糟糕名称？ CustomerID = Customer.ID 非常清楚，因为您看到您正在将外键与主键连接起来；这不是多余的，因为两侧是两个不同的东西。单个字符命名是 IMO 的不良做法。

【解决方案2】：

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

它避免了由复数歧义引起的错误和错误。程序员并不完全以其拼写专业知识而闻名，而且将某些单词复数会令人困惑。例如，复数词是以“es”结尾还是只是“s”？是人还是人？当您与大型团队一起处理项目时，这可能会成为一个问题。例如，团队成员使用不正确的方法来复数他创建的表的实例。当我与此表交互时，它已在我无权访问或修复所需时间太长的代码中全部使用。结果是我每次使用时都必须记住拼错表格。与此非常相似的事情发生在我身上。您越容易使团队中的每个成员能够始终如一地轻松地使用准确、正确的表名，而不会出现错误或不必一直查找表名，就越好。单数版本在团队环境中更容易处理。
如果您使用表名的单数版本并在主键前加上表名前缀，您现在可以轻松地根据主键确定表名，反之亦然，仅通过代码即可。您可以得到一个包含表名的变量，将“Id”连接到末尾，您现在可以通过代码获得表的主键，而无需进行额外的查询。或者，您可以从主键末尾截去“Id”，以通过代码确定表名。如果您使用没有表名的“id”作为主键，那么您无法通过代码从主键中确定表名。此外，大多数人将表名复数并在 PK 列前加上表名，在 PK 中使用单数形式的表名（例如 statuses 和 status_id），根本无法做到这一点。
如果您将表名设为单数，则可以让它们与它们所代表的类名匹配。再一次，这可以简化代码并允许您做一些非常简洁的事情，例如通过只有表名来实例化一个类。它还只是使您的代码更加一致，从而导致...
如果您将表名设为单数，则可以使您的命名方案在每个位置都保持一致、有条理且易于维护。您知道，在代码中的每个实例中，无论是列名、类名还是表名，它都是完全相同的名称。这使您可以进行全局搜索以查看使用数据的任何地方。当您将表名复数时，在某些情况下您将使用该表名的单数版本（它变成的类，在主键中）。没有某些情况下您的数据被称为复数而某些情况下被称为单数是有意义的。

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

【讨论】：

这是一个很好的推理。争论似乎是匹配集合名还是类名，这是对类名方法的一个很好的解释。谢谢！

【解决方案3】：

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

【讨论】：

注意使用的标准：表包含多个东西，用户有一个名字，大写的T-SQL关键字，Pascal大小写的表定义。
错字：Lastname 应该是 LastName
表名应该是单数，即：用户而不是用户
注意表名是复数的；因为他们持有 Users，而不是 User。

【解决方案4】：

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

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

表的单数名称
列的单数名称
表前缀的架构名称（例如：SchemeName.TableName）
帕斯卡套管（也称为上驼峰套管）

【讨论】：

wilsonmar.com/sql_adventureworks.htm 是对 AdventureWorks 架构的出色分析。
我不会依赖微软的任何标准——如果你查看他们的北风数据库，你会发现他们使用复数表、单数列名、表的模式前缀、主键列的表前缀，匈牙利风格的约束前缀和最糟糕的空格“”用于多词表名。此外，SQLServer 的系统表使用复数形式，因此 AdventureWorks 似乎是这群人中的害群之马。
我认为这里的主要问题是 Singular table name crowd 似乎将 table 视为实体，而不是 Plural crowd 所做的 table 中的行。你必须问你自己它是什么。如果表只是行的容器，使用复数命名不是更合乎逻辑吗？您永远不会以单数形式命名集合，那么为什么要以单数形式命名表呢？为什么不一致？我听到了所有关于它们如何在连接中排序和使用的争论，但这些争论似乎都非常站不住脚。如果这一切都归结为偏好，我将保持一致性和多元化。
还要考虑潮流的走向。它似乎朝着复数表名的方向发展，特别是因为 SQL Server 中的所有系统表都是复数，而 Entity Framework 的默认值是开箱即用的复数。如果这是微软的立场，我想朝着我们 20 年后的方向前进。甚至 Oracle 的数据库约定都使用复数表名。想想有多少 c# 开发人员在引入“var”关键字时讨厌它，现在它已被广泛接受的定义变量的方式。
@Jasmine - 我明白你的观点，尽管我认为你无意中将你的示例表命名为倒序。 “TableOfInvoices”应该缩短为“Invoices”，这是我更喜欢的。您可能指的是“InvoiceTable”，这对缩短“Invoice”很有意义。

【解决方案5】：

没有。表应以其所代表的实体命名。人，而不是人是您如何指代其中一条记录所代表的人。
再说一遍。 FirstName 列确实不应该称为 FirstNames。这完全取决于您想用该列表示什么。
没有。
是的。为清楚起见。如果您需要像“FirstName”这样的列，则使用大小写会更容易阅读。

好的。那是我的 0.02 美元

【讨论】：

为数字 3 增加一些清晰度 - 前缀是将元数据嵌入列名的一种方式。出于与（过度使用）匈牙利符号相同的原因，在任何现代数据库中都不需要这样做。
`从订单中选择前15名'或'从订单中选择前15名'？后者是我（人类）的偏好。
@Ian Boyd：是的：从 Report R INNER JOIN VisitReport VR 中选择前 100 个 * R.ReportID = VR.ReportID。这一切都取决于你如何看待它。如果你在罐子上放一张柠檬的照片，你就会知道里面有柠檬，而不需要外面有两个柠檬来表明它可以是复数。当然，你可以用文字“柠檬”来标记它。但它也可能是“柠檬”。要获取名为“柠檬”的资源，请转到此处。
添加 0.01 美元用于在列名中使用大写字母，并添加另外 0.01 美元用于在列名中使用下划线，以便更容易区分列名。总计 = 我给你的 0.02 美元捐款！
"表应该以其所代表的实体命名" 表是实体的集合。虽然表也是实体，但它是“表”类型的实体，添加到其名称中毫无意义。

【解决方案6】：

我们的偏好：

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

Update person set property = 'value' 作用于表中的每个人。
Select * from person where person.name = 'Greg' 返回人员行的集合/行集。
列名应该是单数吗？
通常是的，除非您违反规范化规则。
我应该为表或列添加前缀吗？
主要是平台偏好。我们更喜欢在列前加上表名。我们不为表添加前缀，但我们为视图 (v_) 和 stored_procedures（sp_ 或 f_（函数））添加前缀。这有助于想要尝试更新 v_person.age 的人，这实际上是视图中的计算字段（无论如何都无法更新）。

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

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

bob = new person()
bob.person_name = 'Bob'
bob.person_dob = '1958-12-21'
... 非常易读和明确。不过这可能会失控：

customer.customer_customer_type_id

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

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

customer_category_customer_type_id

...长边有点（！）。
我应该在命名项目时使用任何大小写吗？是的 - 小写:)，带下划线。这些是非常易读和跨平台的。加上上面的 3 也是有道理的。

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

【讨论】：

SELECT * FROM people AS person WHERE person.name = 'Greg' 对我来说听起来最自然。
@Zuko 大多数情况下，表主键的命名约定是<table name><id>，例如PersonID 或Person_ID 等。因此，不要以复数形式将表命名为每条记录都是一个单独的人而不是人。
“你永远不知道表格将包含什么（0,1 或许多项目）”，那么如果你不知道为什么要单数呢？在 99% 的情况下，表格将包含超过 1 行，否则您可以考虑重新设计您的系统。
bob.person_name = 'Bob' bob.person_dob = '1958-12-21' 抱歉，但我不认为这是可读的代码。首先，person_name，代码中的下划线远非可读。当然在代码中它应该只是 bob.name 和 bob.dob。关于命名？再次抱歉，所有带下划线的小写字母对我来说似乎很旧且无法阅读。

【解决方案7】：

聚会很晚了，但我仍然想在列前缀方面加两分钱

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

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

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

我认为这两个论点都有缺陷。在不使用前缀的情况下解决这两个问题很容易。这是我的建议：

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

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

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

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

【讨论】：

正如你所提到的，你不能依赖每一个有 table.column 的案例。程序员会在一个地方忘记，然后你的全局查找和替换就破坏了你的整个程序。或者您将其设为规则，有人会认为他通过使用表的别名来满足规则，从而再次挫败全局查找。此外，如果您想通过某种数据库类来组织代码（任何优秀的程序员都会这样做），有时您只需将列名传递给 db 函数或仅将列名放在一个变量。
@janb：我完全支持你的回答。我还想补充一点，使用文本搜索查找依赖项是导航代码的野蛮方式。一旦人们摆脱了那种野蛮的搜索习惯——他们将开始使用良好的命名，即 table.column。所以问题不在于命名风格，问题在于为野蛮人制作的糟糕工具。
你的论点有缺陷。它的问题是它可以双向工作并且不会增加任何优势。你说，要解决这个问题，总是写 table.column，因为你已经在写 table_column。好吧，你也可以说只写 table_column，因为你已经在写 table.column。换句话说，除了引入可能的错误并且不执行约定之外，您的答案之间没有区别。这就是我们有一个“私人”关键字的原因。我们可以相信程序员总是正确地使用类变量，但是关键字强制它并消除了可能的错误。

【解决方案8】：

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

【讨论】：

羊群是一群羊。 User不是一组用户。

【解决方案9】：

我对此的看法是：

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

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

数据库中的表实际上是该实体的集合，一旦使用 set-logic 就更有意义：

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

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

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

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

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

4) 无论你想要什么，我都会推荐 CapitalCase

我认为其中任何一个都没有一套绝对的指导方针。

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

【讨论】：

CapitalCase 到底是什么？
@ViRuSTriNiTy 他的意思可能是pascal case
Keith，在第 3 号上，我两者都做，而且我不一致（但我离题了），但我不明白为什么有一个描述性的列名是不好的，只要它不是落水，与表格，变量等相同。
@johnny 这还不错，因此，只是不需要。为什么要输入你不需要的东西？此外，大多数智能感知主要使用名称的开头，因此如果您有 Product.ProductName、Product.ProductID、Product.ProductPrice 等，键入 Product.P 会为您提供所有前缀字段。

【解决方案10】：

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

列名：它应该是单数的，只有这样它才能表示它将保持一个原子值并确认归一化理论。但是，如果有 n 个相同类型的属性，那么它们应该以 1、2、...、n 等为后缀。

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

外壳：应该是骆驼壳

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

【讨论】：

所以你是说表是实体？还是表中的行是实体？对我来说，表格是行的集合——因此是实体的集合，这意味着复数。

【解决方案11】：

我知道这已经晚了，这个问题已经得到很好的回答，但我想就#3关于列名前缀的问题发表意见。

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

例如给定表“customer”和“address”，让我们分别使用前缀“cust”和“addr”。 “客户”将包含“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%';

【讨论】：

那你不能再reliably find every line of code that touches a particular column...这不是重点吗？
@Raveren - 你仍然可以。如果您所做的只是“SELECT *”，那么查询与此目的无关。当/如果稍后，您使用该查询的结果时，您必须使用列名来处理其数据，所以这是您需要在代码中担心的地方，而不是 SQL 语句。
我很好奇什么情况下需要 SELECT *？我当然不希望任何人在生产代码中使用它。是的，它对于即席查询和找出哪些数据使您的多重连接查询结果变得奇怪很有用，但我认为生产代码中没有地方需要它。
除非您使用非 OO 语言编写整个应用程序，否则拥有一个像样的 ORM 层会使这个论点变得多余。
因此，由于这个答案，我决定尝试在一个大型项目上使用表前缀，并认为我会报告回来。它确实使重构表变得非常容易，这太棒了！然而，这比我预想的痛苦更大。我们的数据库有很多复杂的命名表。很容易记住 Cust 是 Customer 的前缀，但不容易记住 HazardVerificationMethod 的前缀。每次我写一个表或字段时，我都不得不停下来考虑前缀。最后，我认为速度和便利性比可搜索性更重要，但我确实觉得这是一次宝贵的体验。

【解决方案12】：

表名单数。假设您正在模拟某人与其地址之间的关系。例如，如果您正在阅读数据模型，您会更喜欢 “每个人可能住在 0,1 或多个地址。”要么 “每个人可能住在 0,1 或多个地址。” 我认为更容易使地址多元化，而不是必须将人重新表述为人。加上集体名词通常与单数形式不同。

【讨论】：

【解决方案13】：

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

【讨论】：

天啊。不。表名绝对是复数。这是一个集合。它里面有很多东西。 “从人中选择 *”。您不是从一个人中选择，而是从多个人中选择！
我一直很喜欢 select 语句如果是复数的话听起来更好的方式。 SELECT id,name FROM contacts WHERE email_address LIKE '%gmail%' 表复数，列单数。再次始终是个人意见的问题。
在处理数据库元数据时，为 tbl、qry 等添加前缀非常有用，如果您正在检查数据库中的对象，具有快速、简单的命名约定可以显着加快理解速度
@Triynko 直到你碰到“XyzStatus”表。状态的复数是状态，但这没有意义。但是你不能选择一个复数，另一个单数。

【解决方案14】：

Essential Database Naming Conventions (and Style)（点击这里查看更多详细说明）

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

【讨论】：

虽然甲骨文建议它与上面的链接链接完全相反。在这里找到甲骨文所说的..ss64.com/ora/syntax-naming.html
This answer has already been given almost 3 years ago...
Oracle 的命名约定是其中最有趣的。e.g. PATIENTS would have a primary key called pa_patient_id_pk !!

【解决方案15】：

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

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

我们对表使用单数名称。表格往往以系统名称（或其首字母缩写词）作为前缀。如果系统复杂，这很有用，因为您可以更改前缀以将表按逻辑分组（即 reg_customer、reg_booking 和 regadmin_limits）。

对于字段，我们希望字段名称包含表的前缀/acryonm（即 cust_address1），我们也更喜欢使用一组标准的后缀（_id 表示 PK，_cd 表示“代码”，_nm代表“姓名”，_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

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

【讨论】：

特别是对于 3 号，我们有一群人都是从同一家公司受雇的，他们试图将旧的命名标准（我们其他人都没有使用）强加于他们所做的任何事情.很烦人。
肯定会使 SQL 不可读；但我想我可以翻译。 cust_nm 应该是 CustomerName，booking_dt 应该是 BookingDate。 reg_customer，我不知道那是什么。
@Ian。目的是你坚持你习惯的命名约定，并保持一致。我总是知道任何日期字段都是 _dt，任何名称字段都是 _nm。 'reg' 是“注册”系统（预订、客户等）的一个示例，所有相关表都将具有相同的前缀。但每个人都有自己的...
我同意一个特定的标准不如有一个一致的标准重要。但有些标准是错误的。 DB2 和列名称，如 CSPTCN、CSPTLN、CSPTMN、CSDLN。人们应该知道，长名称已经被发明了——我们有能力让事情变得可读。
多年来，我在我开发和销售的应用程序的表格末尾添加了新列。有时，我在我的列中使用英文名称，有时我使用西班牙语，有时我将列重新用于其他内容，而不是删除它们并添加一个具有适当描述性名称的新列。我故意这样做是为了混淆我的源代码，以防其他人试图破解或反向工程我的代码。只有我能理解，别人会沮丧！..这样，他们总是要依靠我做任何事情！

【解决方案16】：

好的，因为我们正在权衡意见：

我认为表名应该是复数。表是实体的集合（表）。每行代表一个实体，表格代表集合。所以我会调用一个 Person 实体表 People（或 Persons，随便你喜欢什么）。

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

SELECT person.Name
FROM People person

有点像 LINQ 的“从人中选择人名”。

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

【讨论】：

@Emtucifor：在英语中，我们不会说“看看那群人中的所有人！”可以预料，对于由单个单词引用的多个事物会出现概念问题。这既不正常也不恰当。 “数据”是特殊的，通常用于指代一定体积的物质，很像“蛋糕”。 “你想要（一块）蛋糕吗？”将表命名为“人员”，因为它包含有关多个个人的信息，这比将其命名为“人员”更有意义。 ROW 的名为“Person”的数据类是有意义的，单数列名也是如此。
@Emtucifor：归根结底，所有语言都是任意和传统的。我只是在争辩说，通常我们将项目集合称为其中项目类型的复数。因此，每行包含有关单个人的信息的行集合将被称为人员集合。但是，如果您想将其称为 Person 的集合，请继续。
@Emtucifor：是的，哈哈。将表命名为“PersonCollection”相当于将其命名为“People”。相比之下，将这样的集合命名为“Person”，这是没有意义的:)
@Emtucifor：那么让我们从另一个角度考虑一下，将命名约定放在一个上下文中。假设您有用于表示行和表的对象类。 “Person”显然对代表一行数据的类有意义。如果您的表也被命名为“Person”，那么您可能会遇到命名冲突或一些混乱。我只是认为用准确的复数命名对象更有意义。包含有关人员数据的行应称为 Person，包含有关人员或多人信息的表称为 People、PersonCollection、Persons 等。
@Josh M. 好吧，不是 either 你走的路。如果您按照我的方式行事，您可以将 People 表别名为“person”并选择 person.Name。问题解决了。 ;-)

【解决方案17】：

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

见Data element name on Wikipedia:

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

与往常一样，规则也有例外，例如始终只有一行的表可能会更好地使用单数名称，例如一个配置表。一致性至关重要：检查您的商店是否有惯例，如果有，请遵守；如果你不喜欢它，那就做一个商业案例来改变它，而不是孤军奋战。

【讨论】：

-1：引用的文本与 ISO/IEC 11179 无关。引用的维基百科页面不应被信任；改为阅读实际标准 (metadata-standards.org/11179/#A5)
@onedaywhen：我对主题的了解不够，无法更正维基百科页面；此外，维基百科页面并没有太多错误，因为它具有误导性 - 它没有明确说 ISO/IEC 11179 包含数据库命名约定，它只是说“ISO/IEC 11179 在命名表和列时适用于一个关系型数据库”。然后它继续提供可能用于关系数据库的命名约定示例。它让您认为该示例是从标准中提取的，而实际上它是由维基百科文章的作者编造的。

【解决方案18】：

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

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

【讨论】：

【解决方案19】：

在我看来：

表名应该是复数。
列名应该是单数。
没有。
CamelCase（我的首选）或 underscore_separated 用于表名和列名。

但是，正如前面提到的，任何约定都比没有约定好。无论您选择如何做，都要记录下来，以便将来的修改遵循相同的约定。

【讨论】：

关于#4，PascalCase...camelCase...snake_case...

【解决方案20】：

查看 ISO 11179-5：命名和识别原则你可以在这里得到它：http://metadata-standards.org/11179/#11179-5

我在这里写了一段时间的博客：ISO-11179 Naming Conventions

【讨论】：

如果您在此处提供摘要，您的答案会更容易获得（=更好）。不过，很棒的指针！

【解决方案21】：

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

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

这是我的答案：

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

命名很困难，但在每个组织中都有可以命名事物的人，并且在每个软件团队中都应该有人负责命名标准并确保命名问题，如 sec_id、 sec_value 和 security_id 在融入项目之前尽早解决。

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

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

【讨论】：

表是定义关系。它们实际上是单数的。前缀很烂。您是否曾经需要将表格更改为视图，反之亦然？尝试使用前缀。如果是视图或表格，有什么区别？
前缀可能有助于我们对两个对象具有相同名称的情况 - 例如函数和存储过程。我将有一个名称为“GetApproverList”的函数，并且具有相同的名称，我想创建一个存储过程，该过程将在内部调用此函数。 Sql 不允许创建两个具有相同名称的对象。

【解决方案22】：


--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
);

这些是我学到的约定，但你应该适应你开发软管使用的任何东西。

复数。它是实体的集合。
是的。属性是实体单一属性的表示。
是的，前缀表名允许轻松跟踪所有约束索引和表别名的命名。
表和列名的 Pascal 大小写，索引和约束的前缀 + ALL 大写。

【讨论】：

ChristianName ...这是一个奇怪的约定。
您的桌子上有序列号吗？有没有人认真地认为这对开发人员有效有意义？
自从这个例子提出来......我个人反对在表名或列名中使用大写首字母缩写词，因为我认为这会使阅读变得更加棘手。所以在这种情况下，我会说 StudentId 比 StudentID 更可取。首字母缩略词在末尾时没什么大不了的，但我在工作中看到了无数的例子，首字母缩略词位于名称的前面或中间，这让你更难在脑海中解析。例如：StudentABCSSN 与 StudentAbcSsn。

【解决方案23】：

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

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

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

以防万一，以下是我的答案：

是的。表格是一组记录、教师或演员，所以...复数形式。
是的。
我不使用它们。
我经常使用的数据库 - Firebird - 将所有内容都保持为大写，所以没关系。无论如何，当我编程时，我会以更容易阅读的方式编写名称，例如 releaseYear。

【讨论】：