SQL 表命名困境：单数与复数名称

Table Naming Dilemma: Singular vs. Plural Names

提问by ProfK

Academia has it that table names should be the singular of the entity that they store attributes of.

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

I dislike any T-SQL that requires square brackets around names, but I have renamed a Userstable to the singular, forever sentencing those using the table to sometimes have to use brackets.

我不喜欢任何需要在名称周围使用方括号的 T-SQL，但我已将一个Users表重命名为单数，永远判刑那些使用该表的人有时不得不使用方括号。

My gut feel is that it is more correct to stay with the singular, but my gut feel is also that brackets indicate undesirables like column names with spaces in them etc.

我的直觉是保持单数更正确，但我的直觉也是括号表示不受欢迎的内容，例如列名中带有空格等。

Should I stay, or should I go?

我应该走还是留？

采纳答案by Tom H

Others have given pretty good answers as far as "standards" go, but I just wanted to add this... Is it possible that "User" (or "Users") is not actually a full description of the data held in the table? Not that you should get too crazy with table names and specificity, but perhaps something like "Widget_Users" (where "Widget" is the name of your application or website) would be more appropriate.

就“标准”而言，其他人已经给出了很好的答案，但我只是想补充一点……“用户”（或“用户”）是否实际上并不是对表中数据的完整描述? 并不是说您不应该对表名和特殊性太着迷，但也许像“Widget_Users”（其中“Widget”是您的应用程序或网站的名称）之类的东西会更合适。

回答by Nestor

I had same question, and after reading all answers here I definitely stay with SINGULAR, reasons:

我有同样的问题，在阅读了这里的所有答案后，我肯定会选择 SINGULAR，原因如下：

Reason 1(Concept). You can think of bag containing apples like "AppleBag", it doesn't matter if contains 0, 1 or a million apples, it is always the same bag. Tables are just that, containers, the table name must describe what it contains, not how much data it contains. Additionally, the plural concept is more about a spoken language one (actually to determine whether there is one or more).

原因 1（概念）。你可以把装苹果的袋子想象成“AppleBag”，不管装0、1还是一百万个苹果，它总是同一个袋子。表只是容器，表名必须描述它包含什么，而不是它包含多少数据。此外，复数概念更多地是关于一种口语（实际上是为了确定是否有一个或多个）。

Reason 2. (Convenience). it is easier come out with singular names, than with plural ones. Objects can have irregular plurals or not plural at all, but will always have a singular one (with few exceptions like News).

原因2。（方便）。单数名称比复数名称更容易出现。对象可以有不规则的复数形式或根本不是复数形式，但总是有一个单数形式（很少有像 News 这样的例外）。

• Customer
• Order
• User
• Status
• News

• 顾客
• 命令
• 用户
• 地位
• 消息

Reason 3. (Aesthetic and Order). Specially in master-detail scenarios, this reads better, aligns better by name, and have more logical order (Master first, Detail second):

原因3。（美学和秩序）。特别是在 master-detail 场景中，这读取更好，按名称对齐更好，并且具有更多的逻辑顺序（Master第一，Detail第二）：

• 1.Order
• 2.OrderDetail

• 1.订单
• 2.订单详情

Compared to:

相比：

• 1.OrderDetails
• 2.Orders

• 1.订单详情
• 2.订单

Reason 4(Simplicity). Put all together, Table Names, Primary Keys, Relationships, Entity Classes... is better to be aware of only one name (singular) instead of two (singular class, plural table, singular field, singular-plural master-detail...)

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

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

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

Once you know you are dealing with "Customer", you can be sure you will use the same word for all of your database interaction needs.

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

Reason 5. (Globalization). The world is getting smaller, you may have a team of different nationalities, not everybody has English as a native language. It would be easier for a non-native English language programmer to think of "Repository" than of "Repositories", or "Status" instead of "Statuses". Having singular names can lead to fewer errors caused by typos, save time by not having to think "is it Child or Children?", hence improving productivity.

原因5。（全球化）。世界越来越小，你可能有一个不同国籍的团队，不是每个人的母语都是英语。非英语母语程序员更容易想到“存储库”而不是“存储库”，或者“状态”而不是“状态”。使用单数名称可以减少因拼写错误而导致的错误，不必考虑“是孩子还是孩子？”，从而节省时间，从而提高生产力。

Reason 6. (Why not?). It can even save you writing time, save you disk space, and even make your computer keyboard last longer!

原因6。（为什么不？）。它甚至可以节省您的书写时间，节省您的磁盘空间，甚至让您的电脑键盘更耐用！

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

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

You have saved 3 letters, 3 bytes, 3 extra keyboard hits :)

您已经保存了 3 个字母、3 个字节、3 次额外的键盘敲击 :)

And finally, you can name those ones messing up with reserved names like:

最后，您可以命名那些与保留名称混淆的名称，例如：

• User > LoginUser, AppUser, SystemUser, CMSUser,...

• 用户 > 登录用户、AppUser、系统用户、CMSUser、...

Or use the infamous square brackets [User]

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

回答by Brian Boatright

If you use Object Relational Mapping tools or will in the future I suggest Singular.

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

Some tools like LLBLGen can automatically correct plural names like Users to User without changing the table name itself. Why does this matter? Because when it's mapped you want it to look like User.Name instead of Users.Name or worse from some of my old databases tables naming tblUsers.strName which is just confusing in code.

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

My new rule of thumb is to judge how it will look once it's been converted into an object.

我的新经验法则是判断它被转换成对象后的外观。

one table I've found that does not fit the new naming I use is UsersInRoles. But there will always be those few exceptions and even in this case it looks fine as UsersInRoles.Username.

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

回答by Ian Mackinnon

I prefer to use the uninflectednoun, which in English happens to be singular.

我更喜欢使用不屈折的名词，它在英语中恰好是单数。

Inflecting the number of the table name causes orthographic problems (as many of the other answers show), but choosing to do so because tables usually contain multiple rows is also semantically full of holes. This is more obvious if we consider a language that inflects nouns based on case (as most do):

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

Since we're usually doing something with the rows, why not put the name in the accusative case? If we have a table that we write to more than we read, why not put the name in dative? It's a table ofsomething, why not use the genitive? We wouldn't do this, because the table is defined as an abstract container that exists regardless of its state or usage. Inflecting the noun without a precise and absolute semantic reason is babbling.

既然我们通常对行做一些事情，为什么不把名字放在宾格中呢？如果我们有一张表，我们写的比读的多，为什么不把名字放在与格中呢？这是一个表的东西，为什么不使用所有格？我们不会这样做，因为表被定义为一个抽象容器，无论其状态或使用情况如何都存在。在没有精确和绝对语义原因的情况下对名词进行变形是胡言乱语。

Using the uninflected noun is simple, logical, regular and language-independent.

使用非屈折名词简单、合乎逻辑、规则且与语言无关。

回答by Michael Haren

What convention requires that tables have singular names? I always thought it was plural names.

什么约定要求表具有单数名称？我一直以为是复数的名字。

A user is added to the Users table.

用户被添加到用户表中。

This site agrees:
http://vyaskn.tripod.com/object_naming.htm#Tables

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

This site disagrees (but I disagree with it):
http://justinsomnia.org/writings/naming_conventions.html

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

---

---

As others have mentioned: these are just guidelines. Pick a convention that works for you and your company/project and stick with it. Switching between singular and plural or sometimes abbreviating words and sometimes not is much more aggravating.

正如其他人所提到的：这些只是指导方针。选择一个适合你和你的公司/项目的约定并坚持下去。在单数和复数或有时缩写词之间切换，有时不是更严重。

回答by Michael Haren

How about this as a simple example:

作为一个简单的例子如何：

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

vs.

对比

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

The SQL in the latter is stranger sounding than the former.

后者中的 SQL 听起来比前者更奇怪。

I vote for singular.

我投票给单数。

回答by Adam Carr

I am of the firm belief that in an Entity Relation Diagram, the entity should be reflected with a singular name, similar to a class name being singular. Once instantiated, the name reflects its instance. So with databases, the entity when made into a table (a collection of entities or records) is plural. Entity, User is made into table Users. I would agree with others who suggested maybe the name User could be improved to Employee or something more applicable to your scenario.

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

This then makes more sense in a SQL statement because you are selecting from a group of records and if the table name is singular, it doesn't read well.

这在 SQL 语句中更有意义，因为您是从一组记录中进行选择，并且如果表名是单数，则它不会很好地读取。

回答by Ash Machine

I stick with singularfor table names and any programming entity.

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

The reason? The fact that there are irregular plurals in English like mouse ? miceand sheep ? sheep. Then, if I need a collection, i just use mousesor sheeps, and move on.

原因？英语中有像mouse这样的不规则复数吗？老鼠和羊？羊。然后，如果我需要一个集合，我只使用鼠标或羊，然后继续。

It really helps the plurality stand out, and I can easily and programatically determine what the collection of things would look like.

它确实有助于突出多元化，我可以轻松地以编程方式确定事物集合的样子。

So, my rule is: everything is singular, every collection of things is singular with an sappended. Helps with ORMs too.

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

回答by Gulzar Nazim

IMHO, table names should be plurallike Customers.

恕我直言，表名应该是复数，比如Customers。

Class names should be singular like Customerif it maps to a row in the Customerstable.

如果类名映射到客户表中的一行，则类名应该像Customer一样是单数。

回答by Jacob Lorensen

Singular. I don't buy any argument involving which is most logical - every person thinks his own preference is most logical. No matter what you do it is a mess, just pick a convention and stick to it. We are trying to map a language with highly irregular grammar and semantics (normal spoken and written language) to a highly regular (SQL) grammar with very specific semantics.

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

My main argument is that I don't think of the tables as a set but as relations.

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

So, the AppUserrelation tells which entities are AppUsers.

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

The AppUserGrouprelation tells me which entities are AppUserGroups

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

The AppUser_AppUserGrouprelation tells me how the AppUsersand AppUserGroupsare related.

的AppUser_AppUserGroup关系告诉了我怎么AppUsers和AppUserGroups有关系。

The AppUserGroup_AppUserGrouprelation tells me how AppUserGroupsand AppUserGroupsare related (i.e. groups member of groups).

该AppUserGroup_AppUserGroup关系告诉我如何相关AppUserGroups以及如何AppUserGroups相关（即组中的组成员）。

In other words, when I think about entities and how they are related I think of relations in singular, but of course, when I think of the entities in collections or sets, the collections or sets are plural.

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

In my code, then, and in the database schema, I use singular. In textual descriptions, I end up using plural for increased readability - then use fonts etc. to distinguish the table/relation name from the plural s.

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

I like to think of it as messy, but systematic - and this way there is always a systematically generated name for the relation I wish to express, which to me is very important.

我喜欢把它看作是凌乱的，但系统的——这样我想表达的关系总是有一个系统生成的名称，这对我来说非常重要。