表命名困境：奇异与多个名称

Question

学术界认为表名应该是他们存储属性的实体的单数。

我不喜欢任何需要方括号的T-SQL，但是我已经将Users表重命名为单数，永远判断那些使用该表的人有时必须使用括号。

我的直觉是，保持单数是更正确的，但我的直觉也是括号表示不受欢迎的人，如列名和空格等等。

我应该留下，还是应该去？

Answer 1

我有同样的问题，在阅读完所有答案后，我绝对会留下奇异的理由：

原因1 （概念）。你可以想到包含像“AppleBag”这样的苹果的包，如果包含0,1或者100万个苹果没关系，它总是相同的包。表只是容器，表名必须描述它包含的内容，而不是它包含的数据量。另外，复数概念更多地是关于口语（实际上是确定是否存在一个或多个）。

原因2 。 （方便）。与复数名称相比，更容易出现奇异名称。对象可以有不规则的复数或根本不是复数，但总是有一个单数（除了新闻之外的少数例外）。

• 客户
• 顺序
• 用户
• 状态
• 新闻

原因3 。 （审美和秩序）。特别是在主 - 详细信息场景中，这更好地读取，更好地按名称对齐，并且具有更多逻辑顺序（Master first，Detail second）：

• 1.Order
• 2.OrderDetail

与：相比：

• 1.OrderDetails
• 2.Orders

原因4 （简单）。总而言之，表名，主键，关系，实体类......最好只知道一个名称（单数）而不是两个（单数类，复数表，奇异字段，单数 - 复数主 - 细节.. 。）

• Customer
• Customer.CustomerID
• CustomerAddress
• public Class Customer {...}
• SELECT FROM Customer WHERE CustomerID = 100

一旦您知道自己正在与“客户”打交道，就可以确定您将使用相同的词来满足您的所有数据库交互需求。

原因5 。 （全球化）。世界变得越来越小，你可能拥有一个不同国籍的团队，而不是每个人都有英语作为母语。非本地英语程序员更容易想到“存储库”而不是“存储库”或“状态”而不是“状态”。具有单一名称可以减少由错别字引起的错误，通过不必考虑“是孩子还是孩子？”来节省时间，从而提高生产力。

原因6 。 （为什么不？）。它甚至可以节省您的写作时间，节省磁盘空间，甚至可以延长计算机键盘的使用寿命！

• SELECT Customer.CustomerName FROM Customer WHERE Customer.CustomerID = 100
• SELECT Customers.CustomerName FROM Customers WHERE Customers.CustomerID = 100

你已经保存了3个字母，3个字节，3个额外的键盘命中：）

最后，你可以说出那些搞乱保留名称的人，比如：

• 用户＆gt; LoginUser，AppUser，SystemUser，CMSUser，...

或使用臭名昭着的方括号[用户]

Answer 2

如果您使用对象关系映射工具，或将来会建议单数。

某些工具（如LLBLGen）可以自动更正“用户到用户”等多个名称，而无需更改表名本身。为什么这很重要？因为当它被映射时你希望它看起来像User.Name而不是Users.Name，或者更糟糕的是我的一些旧数据库表命名tblUsers.strName，这在代码中只是令人困惑。

我的新经验法则是判断它在转换为物体后的外观。

我找到的一个表不适合我使用的新命名是UsersInRoles。但总会有少数例外情况，即使在这种情况下它看起来也很好，如UsersInRoles.Username。

Answer 3

就“标准”而言，其他人给出了相当不错的答案，但我只是想补充一下......“用户”（或“用户”）是否可能实际上并不是对所持数据的完整描述在桌子上？并不是说你应该对表名和特异性过于疯狂，但也许类似“Widget_Users”（其中“Widget”是你的应用程序或网站的名称）会更合适。

Answer 4

我更喜欢使用未反射的名词，英语恰好是单数。

改变表名的数量会导致拼写问题（正如许多其他答案所示），但选择这样做是因为表通常包含多行，因此在语义上也充满了漏洞。如果我们考虑一种基于案例（大多数情况下）会改变名词的语言，这一点就更加明显了：

由于我们通常会对行进行某些操作，为什么不把这个名字放在指控的情况下呢？如果我们写的表比我们读的要多，为什么不把这个名字写成dative？它是 的表格，为什么不使用genitive呢？我们不会这样做，因为该表被定义为一个抽象容器，无论其状态或用途如何都存在。在没有精确和绝对语义原因的情况下改变名词是喋喋不休。

使用未反射的名词是简单的，逻辑的，规则的和与语言无关的。

Answer 5

什么约定要求表具有单数名称？我一直认为这是多个名字。

用户被添加到Users表中。

本网站同意：
http://vyaskn.tripod.com/object_naming.htm#Tables

本网站不同意（但我不同意）：
http://justinsomnia.org/writings/naming_conventions.html

---

正如其他人所说：这些只是指导方针。选择适合您和您公司/项目的惯例并坚持下去。在单数和复数之间切换或有时缩写单词有时不会更加恶化。

Answer 6

这是一个简单的例子：

SELECT Customer.Name, Customer.Address FROM Customer WHERE Customer.Name > "def"

VS

SELECT Customers.Name, Customers.Address FROM Customers WHERE Customers.Name > "def"

后者的SQL听起来比前者更陌生。

我投票赞成奇异。

Answer 7

我坚信在实体关系图中，实体应该用一个单数名称来反映，类似于一个单数的类名。实例化后，名称将反映其实例。因此，对于数据库，实体在制成表格（实体或记录的集合）时是复数形式。实体，用户被制成表用户。我同意其他人的意见，他们可能会建议将用户名称改进为员工，或者更适用于您的场景。

这在SQL语句中更有意义，因为您从一组记录中进行选择，如果表名是单数，则读取效果不佳。

Answer 8

我坚持使用单数来表名和任何编程实体。

原因？英语中存在不规则复数的事实，例如鼠标⇒老鼠和绵羊⇒绵羊。然后，如果我需要集合，我只需使用 mouses 或 sheeps ，然后继续前进。

这确实有助于众多人脱颖而出，我可以轻松地以编程方式确定事物的集合。

所以，我的规则是：一切都是单数，每个事物的集合都是单数的，附加了 s 。也帮助ORM。

Answer 9

奇异。我不买任何涉及最合乎逻辑的论据 - 每个人都认为他自己的偏好是最合乎逻辑的。无论你做什么都是一团糟，只需选择一个约定并坚持下去。我们试图将具有高度不规则语法和语义（正常的口语和书面语言）的语言映射到具有非常特定语义的高度规则（SQL）语法。

我的主要论点是，我不认为这些表是一个集合，而是作为关系。

因此，AppUser关系告诉哪些实体是AppUsers。

AppUserGroup关系告诉我哪些实体是AppUserGroups

AppUser_AppUserGroup关系告诉我AppUsers和AppUserGroups是如何相关的。

AppUserGroup_AppUserGroup关系告诉我AppUserGroups和AppUserGroups是如何相关的（即群组成员）。

换句话说，当我考虑实体及其相关性时，我会以单数形式考虑关系，但当然，当我想到集合或集合中的实体时，集合或集合是复数。

在我的代码中，然后在数据库模式中，我使用单数。在文本描述中，我最终使用复数来提高可读性 - 然后使用字体等来区分表/关系名称和复数s。

我喜欢把它看成是凌乱的，而是系统的 - 这种方式总是会为我想表达的关系系统地生成名称，这对我来说非常重要。

Answer 10

恕我直言，表格名称应为复数，例如 Customers 。

如果类名映射到 Customers 表中的一行，则类名应该像 Customer 一样。

Answer 11

我也会选择复数，并且在前面提到的用户困境中，我们会采用方括号方法。

我们这样做是为了在数据库体系结构和应用程序体系结构之间提供一致性，并且基本理解 Users 表是 User 值的集合，而不是<代码工件中的em> Users 集合是 User 对象的集合。

让我们的数据团队和我们的开发人员使用相同的概念语言（虽然并不总是相同的对象名称），这样可以更容易地在他们之间传达想法。

Answer 12

我个人更喜欢使用复数名称来代表一个集合，它对我的​​关系思维来说只是“听起来”更好。

在这个时刻，我正在使用单数名称为我的公司定义数据模型，因为大多数工作人员对此感到更加舒适。 有时你只需要让每个人的生活更轻松，而不是强加你的个人喜好。 （这就是我在这个帖子中的结果，以确认命名表的“最佳实践”应该是什么）

在阅读了本帖中的所有争论之后，我得出了一个结论：

我喜欢我的蜂蜜煎饼，无论每个人最喜欢的味道是什么。但如果我正在为其他人做饭，我会尽力为他们服务。

Answer 13

奇异。我将调用一个包含一堆用户行表示对象'us​​ers'的数组，但该表是'用户表'。将表视为只包含它所包含的行的集合是错误的，IMO;表是元数据，行集分层附加到表，它不是表本身。

当然，我总是使用ORM，并且使用多个表名编写的ORM代码看起来很愚蠢。

Answer 14

我不喜欢复数表格名称，因为英语中的某些名词不可数（水，汤，现金）或者当你使它成为可数时意义发生变化（鸡与鸡，肉与鸟）。 我也不喜欢使用表名或列名的缩写，因为这样做会为已经陡峭的学习曲线增加额外的斜率。

具有讽刺意味的是，由于USER (Transac-SQL)，我可能会将User作为例外并将其称为Users，因为如果我不需要，我也不喜欢在表格周围使用括号。

我还想将所有ID列命名为Id，而不是ChickenId或ChickensId（复数人员对此做了什么？）。

所有这一切都是因为我对数据库系统没有适当的尊重，我只是从习惯和懒惰中重新应用OO命名约定（如Java's）的单一技巧 - 小马知识。我希望有更好的IDE支持复杂的SQL。

Answer 15

我实际上一直认为使用多个表名是流行的惯例。到目前为止，我一直使用复数。

我能理解奇异表名的论据，但对我来说复数更有意义。表名通常描述表包含的内容。在规范化数据库中，每个表都包含特定的数据集。每行都是一个实体，表包含许多实体。因此，表名的复数形式。

汽车表的名称为 cars ，每行都是汽车。我承认以table.field方式指定表和字段是最佳做法，并且具有单个表名更具可读性。但是在以下两个例子中，前者更有意义：

SELECT * FROM cars WHERE color='blue'
SELECT * FROM car WHERE color='blue'

老实说，我将重新考虑我对这个问题的立场，我将依赖于我正在开发的组织使用的实际惯例。但是，我认为对于我的个人约定，我会坚持使用多个表名。对我而言更有意义。

Answer 16

我们运行类似的标准，在编写脚本时我们要求[]围绕名称，以及适当的模式限定符 - 主要是通过SQL语法对未来的名称争夺进行对冲。

SELECT [Name] FROM [dbo].[Customer] WHERE [Location] = 'WA'

这在过去拯救了我们的灵魂 - 我们的一些数据库系统已经从SQL 6.0到SQL 2005运行了10多年 - 远远超过了预期的寿命。

Answer 17

我是单个表名的粉丝，因为他们使用CASE语法使我的ER图更容易阅读，但通过阅读这些回复，我感觉它从未如此流行？我个人喜欢它。有一个很好的概述，例子说明当您使用单数表名称时，模型的可读性，为您的关系添加动作动词以及为每个关系形成好的句子。对于一个20表数据库来说，这有点过分，但如果你有一个包含数百个表和复杂设计的数据库，你的开发人员如何在没有良好可读图的情况下理解它？

http://www.aisintl.com/case/method.html

至于为表格和视图添加前缀，我绝对讨厌这种做法。在给予他们可能不良信息之前，根本不给任何人提供信息。任何浏览数据库对象的人都可以很容易地从视图中告诉表，但是如果我有一个名为tblUsers的表，由于某种原因我决定将来重组为两个表，并使用一个视图统一它们以防止破坏旧代码我现在有一个名为tblUsers的视图。在这一点上，我留下了两个没有吸引力的选项，留下一个以tbl前缀命名的视图，这可能会使一些开发人员感到困惑，或者强制使用另一个层，要么重写中间层或应用程序以引用我的新结构或名称viewUsers。这否定了恕我直言的大部分观点。

Answer 18

表格：复数

  

用户表中列出了多个用户。

模特：单数

  

可以从用户表中选择单个用户。

控制器：复数

  

http://myapp.com/users会列出多个用户。

无论如何，这是我对它的看法。

Answer 19

服务器本身的系统tables/views（SYSCAT.TABLES，dbo.sysindexes，ALL_TABLES，information_schema.columns等）几乎总是复数。我想为了保持一致性，我会跟随他们的步伐。

Answer 20

这可能有点多余，但我建议保持谨慎。重命名表不一定是坏事，但标准化就是这样;一个标准 - 这个数据库可能已经“标准化”，但是很糟糕:) - 我建议一致性是一个更好的目标，因为这个数据库已经存在，并且可能它只包含2个表。

除非你能够标准化整个数据库，或者至少计划为此目的而努力，否则我怀疑表名只是冰山一角，专注于手头的任务，忍受命名不佳的对象的痛苦，可能符合您的最佳利益 -

实际一致性有时是最好的标准......：）

my2cents ---

Answer 21

我的观点是语义，具体取决于您如何定义容器。例如，“苹果袋”或简称为“苹果”或“苹果袋”或“苹果”。

实施例：     “大学”表可以包含0个或更多学院     “学院”表可以包含0个或更多同事

a "student" table can contain 0 or more students 
a table of "students" can contain 0 or more students.

我的结论是，两者都很好，但你必须定义你（或与之交互的人）在引用表格时会如何处理; “x表”或“xs表”

Answer 22

可能的替代方案：

• 重命名表SystemUser
• 使用括号
• 保留多个表名。

使用支架的IMO在技术上是最安全的方法，虽然它有点麻烦。 IMO是其中的6个，另外6个，你的解决方案实际上归结为个人/团队偏好。

Answer 23

我总是使用单数，因为这就是我所教的。然而，在最近创建一个新架构时，我很长时间以来第一次主动决定维护这个约定只是因为......它更短。在每个表名的末尾添加's'对我来说似乎没有用，因为在每个表前加上'tbl_'。

Answer 24

我认为使用单数是我们在大学里所教的。但与此同时，可以认为，与面向对象编程不同，表不是其记录的实例。

由于英语中存在多种违规行为，我认为我现在正倾向于支持单数。在德语中，由于没有一致的复数形式，情况更糟糕 - 有时你无法判断一个单词是否为复数而没有前面的指定文章（der / die / das）。而在中文中，无论如何都没有复数形式。

Answer 25

正如其他人在此提到的那样，约定应该是增加易用性和可读性的工具。不是折磨开发商的束缚或俱乐部。

尽管如此，我个人的偏好是对表格和列使用单数名称。这可能来自我的编程背景。类名通常是单数，除非它们是某种集合。在我看来，我正在存储或阅读有问题的表中的个别记录，所以奇异对我来说是有道理的。

这种做法还允许我为那些存储我的对象之间多对多关系的表保留多个表名。

我也试图避免表格和列名中的保留字。在这里讨论的情况下，更有意义的是，与用户的单一约定相反，以避免需要封装使用User的保留字的表。

我喜欢以有限的方式使用前缀（tbl用于表名，sp_用于proc名称等），尽管许多人认为这会增加混乱。我也更喜欢CamelBack名称下划线，因为在键入名称时我总是最后点击+而不是_。许多其他人不同意。

以下是命名惯例指南的另一个很好的链接：http://www.xaprb.com/blog/2008/10/26/the-power-of-a-good-sql-naming-convention/

请记住，您的约定中最重要的因素是对与该数据库交互的人员有意义。在命名惯例方面，没有“一环统治所有”。

Answer 26

如果我们查看MS SQL Server's系统表，则Microsoft指定的名称位于plural。

Oracle的系统表以singular命名。虽然其中一些是复数。 Oracle建议使用多个用户定义的表名。 他们推荐一件事并跟随另一件事并没有多大意义。 这两个软件巨头的建筑师用不同的惯例命名他们的桌子也没有多大意义......毕竟，这些人是什么......博士的？

我确实记得在学术界，推荐是单数的。

例如，当我们说：

select OrderHeader.ID FROM OrderHeader WHERE OrderHeader.Reference = 'ABC123'

也许b / c每个ID都是从特定的一行中选出的......？

Answer 27

我曾经在“用户”表中使用“Dude” - 相同的短字符数，与关键字没有冲突，仍然是对通用人类的引用。如果我不担心可能会看到代码的闷头，我会保持这种方式。

Answer 28

我一直认为这是一个愚蠢的惯例。我使用多个表名。

（我相信这个策略背后的理性是它使ORM代码生成器更容易生成对象和集合类，因为从单数名称生成复数名称比反之亦然更容易）

Answer 29

我只使用名词作为拼写相同的表名，无论是单数还是复数：

驼鹿 鱼 鹿 飞机 您 裤子 短裤 眼镜 剪刀 种类 后代

Answer 30

表的SQL定义实际上是表的一个潜在行的定义，而不是集合。因此，该定义中使用的名称必须指定行的类型，而不是集合的名称。喜欢复数的人因为在英语陈述中读得好，需要开始更加逻辑地思考并查看实际使用表所涉及的所有逻辑和编程代码。这些注释中提到的几个很好的理由是使用单数表名。这些包括非常好的理由不使用复数表名。 “读得好”根本不应该是任何理由，特别是因为有些人可能会以不同的方式阅读这个想法。

Answer 31

我只想说明为什么我使用单数名称。

例如，我需要从用户那里获取所有字段：

-- Select every fields from 'user' table
SELECT * FROM user

我需要21岁用户的名字：

-- Select every fields from 'user' table which have 21 years old
SELECT * FROM user WHERE age = '21'

当然，复数方式可以通过相同的方式使用，但是对于我的大脑来说，我认为这是正确的方法。

Answer 32

准则就是这样的。它并非“一成不变”，这就是为什么你可以选择忽略它们。

我想说，拥有多元化的表名在逻辑上更直观。毕竟，表是实体的集合。除了提到的其他替代方案，我通常会在表名上看到前缀......

• tblUser
• tblThis
• tblThat
• tblTheOther

我并不是说这是要走的路，我也看到空间在表名中使用了很多，我很厌恶。我甚至遇到过像愚蠢人物一样的字段名称？好像说这个字段回答了一个问题。

Answer 33

我总是使用单数表名，但是，如前所述，最重要的是要保持一致并对所有名称使用相同的表单。

我不喜欢复数表名称，组合名称会变得很奇怪。例如，如果您有一个名为Users的表，并且您想要为用户存储属性，则会生成名为UsersProperties的表...

Answer 34

如果你去那里会有麻烦，但是如果你留下它将会加倍。

我更倾向于反对一些假定的非复数命名约定，而不是命名我的表后可能是一个保留字。

Answer 35

我没有在之前的任何答案中清楚地看到这一点。在使用表时，许多程序员都没有正式的定义。我们经常根据“记录”或“行”进行直观沟通。但是，对于非规范化关系的一些例外，通常设计表以使非键属性和键之间的关系构成集合理论函数。

可以将函数定义为两个集合之间的交叉积的子集，其中该组键中的每个元素在映射中最多出现一次。因此，从这个角度出现的术语往往是单一的。人们在涉及函数的其他数学和计算理论（例如代数和lambda演算）中看到相同的单数（或至少，非复数）约定。

Answer 36

如果您使用某些框架（如Zend Framework（PHP）），那么对表类使用复数形式而对行类使用单数形式是明智的。

所以说你创建了一个表对象$ users = new Users（）并且已经将行类声明为User，你也可以调用新的User（）。

现在，如果对表名使用单数形式，则必须执行类似新UserTable（）的操作，其中行为新UserRow（）。对我而言，这看起来比只有对象的Users（）和行的User（）对象更为笨拙。

Answer 37

没有“惯例”要求表名是单数的。

例如，我们在评级过程使用的数据库上有一个名为“REJECTS”的表，其中包含从一次运行程序中拒绝的记录，我没有看到任何理由不对该表使用复数（命名为“拒绝“本来就很有趣，或者过于乐观”。

关于其他问题（引用）它取决于SQL方言。 Oracle不需要围绕表名引用。

Answer 38

TABLE名称是表结构的一个定义。 VIEW或QUERY名称是（一个或多个）表的视图或查询的一个定义。 TABLE，VIEW或QUERY可能包含以下内容之一：

0记录 1条记录 许多记录。

为什么你想在一个对象名称的末尾添加's'？ 你想通过将这个's'放在一个对象名的末尾来表示什么？

如果要区分，请添加“_tbl”。 一个视图是'_vew'（不是愚蠢的'_v'约定）。

最少3个字符的后缀 - 这会使讨论停止。

表是一个DB对象 - 与其他对象没什么不同。

保存3个字符除了意义清晰之外什么也不保存。

红色; - ）

Answer 39

在寻找良好的命名保密措施时，出现以下混淆，我应该这样命名：

1）acc。到表所持有的 例如：用户表。它总是复数。那么，用户

2）acc。到什么记录 例如：用户表中的记录将是单个用户。所以，用户。

现在，主要是user_roles的问题。 案例1：acc。到第一个命名约定，users_roles 这个名字的含义，用户及其角色。

案例2：acc。到第二个命名约定user_role 这个名字的意思，用户和他的角色。

良好的命名约定是提供实体关系的其他想法，尤其是在存储多对多关系时。

在这里，根据情景，我们应该确定信息集。

在users表中，所有形成的集都是唯一用户。 在Roles表中，形成的所有集合都是唯一的角色。 在用户和角色关系表中，可以使用不同的角色形成用户组，从而可以了解存储的多个关系。

I would prefer,
Users table => user
Roles table => role
users role relationship table => user_roles

Answer 40

这两个网站都有不同的论文，我认为你只需要选择自己的一面。就个人而言，我更喜欢Plurar用于表格命名，当然还有单数用于列命名。

我喜欢你怎么读这个：

SELECT CustomerName FROM Customers WHERE CustomerID = 100;

我们真的有OOP，而且很棒，但是大多数人都在使用关系数据库，没有对象数据库。没有必要遵循关系数据库的OOP概念。

另一个例子，你有一个表Teams，它保留TeamID，TeamColor但也是PlayerID，并且对于一定数量的PlayerID具有相同的teamID和TeamColor ...

玩家属于哪个团队？

SELECT * FROM Teams WHERE PlayerID = X

X Team的所有玩家？

SELECT * FROM Players INNER JOIN Teams ON Players.PlayerID = Teams.PlayerID WHERE Teams.TeamID = X

这一切听起来对你好吗？

无论如何，还要看看W3Schools使用的命名约定：

http://www.w3schools.com/sql/sql_join_inner.asp

Answer 41

我通过命名表“Employee”（实际上是“Employees”）解决了同样的问题。我试图尽可能远离任何可能保留字的冲突。甚至“用户”也让我感到非常不舒服。