SELECT Customer.CustomerName FROM Customer WHERE Customer.CustomerID = 100
SELECT Customers.CustomerName FROM Customers WHERE Customers.CustomerID = 103
您已保存 3 个字母、3 个字节、3 个额外键盘点击:)
最后，你可以用保留名称来命名那些混乱的人，例如：
User > LoginUser、AppUser、SystemUser、CMSUser，...
或者使用臭名昭著的方括号 [User]
I had same question, and after reading all answers here I definitely stay with SINGULAR, reasons:
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).
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).
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):
1.Order
2.OrderDetail
Compared to:
1.OrderDetails
2.Orders
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...)
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.
Reason 6. (Why not?). It can even save you writing time, save you disk space, and even make your computer keyboard last longer!
SELECT Customer.CustomerName FROM Customer WHERE Customer.CustomerID = 100
SELECT Customers.CustomerName FROM Customers WHERE Customers.CustomerID = 103
You have saved 3 letters, 3 bytes, 3 extra keyboard hits :)
And finally, you can name those ones messing up with reserved names like:
User > LoginUser, AppUser, SystemUser, CMSUser,...
I prefer to use the uninflected noun, 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 of something, 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.
If you use Object Relational Mapping tools or will in the future I suggest 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.
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.
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.
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.
我坚信，在实体关系图中，实体应该用单一名称来反映，类似于单一的类名称。 一旦实例化，名称就会反映其实例。 因此，对于数据库来说，当制成表（实体或记录的集合）时，实体是复数的。 实体，User做成表Users。 我同意其他人的建议，他们建议可以将 User 名称改进为 Employee 或更适合您的场景。
这在 SQL 语句中更有意义，因为您是从一组记录中进行选择，如果表名是单数，则读起来不太好。
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.
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.
I stick with singular for table names and any programming entity.
The reason? The fact that there are irregular plurals in English like mouse ⇒ mice and sheep ⇒ sheep. Then, if I need a collection, i just use mouses or sheeps, and move on.
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 s appended. Helps with ORMs too.
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.
My main argument is that I don't think of the tables as a set but as relations.
So, the AppUser relation tells which entities are AppUsers.
The AppUserGroup relation tells me which entities are AppUserGroups
The AppUser_AppUserGroup relation tells me how the AppUsers and AppUserGroups are related.
The AppUserGroup_AppUserGroup relation tells me how AppUserGroups and AppUserGroups are related (i.e. groups member of groups).
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.
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.
I also would go with plurals, and with the aforementioned Users dilemma, we do take the square bracketing approach.
We do this to provide uniformity between both database architecture and application architecture, with the underlying understanding that the Users table is a collection of User values as much as a Users collection in a code artifact is a collection of User objects.
Having our data team and our developers speaking the same conceptual language (although not always the same object names) makes it easier to convey ideas between them.
I personaly prefer to use plural names to represent a set, it just "sounds" better to my relational mind.
At this exact moment i am using singular names to define a data model for my company, because most of the people at work feel more confortable with it. Sometimes you just have to make life easier to everyone instead of imposing your personal preferences. (that's how i ended up in this thread, to get a confirmation on what should be the "best practice" for naming tables)
After reading all the arguing in this thread, i reached one conclusion:
I like my pancakes with honey, no matter what everybody's favorite flavour is. But if i am cooking for other people, i will try to serve them something they like.
I've actually always thought it was popular convention to use plural table names. Up until this point I've always used plural.
I can understand the argument for singular table names, but to me plural makes more sense. A table name usually describes what the table contains. In a normalized database, each table contains specific sets of data. Each row is an entity and the table contains many entities. Thus the plural form for the table name.
A table of cars would have the name cars and each row is a car. I'll admit that specifying the table along with the field in a table.field manner is the best practice and that having singular table names is more readable. However in the following two examples, the former makes more sense:
SELECT * FROM cars WHERE color='blue'
SELECT * FROM car WHERE color='blue'
Honestly, I will be rethinking my position on the matter, and I would rely on the actual conventions used by the organization I'm developing for. However, I think for my personal conventions, I'll stick with plural table names. To me it makes more sense.
Singular. I'd call an array containing a bunch of user row representation objects 'users', but the table is 'the user table'. Thinking of the table as being nothing but the set of the rows it contains is wrong, IMO; the table is the metadata, and the set of rows is hierarchically attached to the table, it is not the table itself.
I use ORMs all the time, of course, and it helps that ORM code written with plural table names looks stupid.
I don't like plural table names because some nouns in English are not countable (water, soup, cash) or the meaning changes when you make it countable (chicken vs a chicken; meat vs bird). I also dislike using abbreviations for table name or column name because doing so adds extra slope to the already steep learning curve.
Ironically, I might make User an exception and call it Users because of USER (Transac-SQL), because I too don't like using brackets around tables if I don't have to.
I also like to name all the ID columns as Id, not ChickenId or ChickensId (what do plural guys do about this?).
All this is because I don't have proper respect for the database systems, I am just reapplying one-trick-pony knowledge from OO naming conventions like Java's out of habit and laziness. I wish there were better IDE support for complicated SQL.
select OrderHeader.ID FROM OrderHeader WHERE OrderHeader.Reference = 'ABC123'
也许 b/c 每个 ID 都是从特定的单行中选择的......？
If we look at MS SQL Server's system tables, their names as assigned by Microsoft are in plural.
The Oracle's system tables are named in singular. Although a few of them are plural. Oracle recommends plural for user-defined table names. That doesn't make much sense that they recommend one thing and follow another. That the architects at these two software giants have named their tables using different conventions, doesn't make much sense either... After all, what are these guys ... PhD's?
I do remember in academia, the recommendation was singular.
For example, when we say:
select OrderHeader.ID FROM OrderHeader WHERE OrderHeader.Reference = 'ABC123'
maybe b/c each ID is selected from a particular single row ...?
We run similar standards, when scripting we demand [ ] around names, and where appropriate schema qualifiers - primarily it hedges your bets against future name grabs by the SQL syntax.
SELECT [Name] FROM [dbo].[Customer] WHERE [Location] = 'WA'
This has saved our souls in the past - some of our database systems have run 10+ years from SQL 6.0 through SQL 2005 - way past their intended lifespans.
The system tables/views of the server itself (SYSCAT.TABLES, dbo.sysindexes, ALL_TABLES, information_schema.columns, etc.) are almost always plural. I guess for the sake of consistency I'd follow their lead.
I've always used singular simply because that's what I was taught. However, while creating a new schema recently, for the first time in a long time, I actively decided to maintain this convention simply because... it's shorter. Adding an 's' to the end of every table name seems as useless to me as adding 'tbl_' in front of every one.
我是单数表名的粉丝，因为它们使我使用 CASE 语法的 ER 图更易于阅读，但通过阅读这些回复，我感觉它从未流行起来？ 我个人很喜欢它。 有一个很好的概述，其中包含示例，说明当您使用单数表名称、向关系添加动作动词以及为每个关系形成良好的句子时，模型的可读性如何。 对于一个包含 20 个表的数据库来说，这有点大材小用，但是如果您的数据库包含数百个表和复杂的设计，那么如果没有良好的可读图表，您的开发人员将如何理解它呢？
I am a fan of singular table names as they make my ER diagrams using CASE syntax easier to read, but by reading these responses I'm getting the feeling it never caught on very well? I personally love it. There is a good overview with examples of how readable your models can be when you use singular table names, add action verbs to your relationships and form good sentences for every relationships. It's all a bit of overkill for a 20 table database but if you have a DB with hundreds of tables and a complex design how will your developers ever understand it without a good readable diagram?
As for prefixing tables and views I absolutely hate that practice. Give a person no information at all before giving them possibly bad information. Anyone browsing a db for objects can quite easily tell a table from a view, but if I have a table named tblUsers that for some reason I decide to restructure in the future into two tables, with a view unifying them to keep from breaking old code I now have a view named tblUsers. At this point I am left with two unappealing options, leave a view named with a tbl prefix which may confuse some developers, or force another layer, either middle tier or application to be rewritten to reference my new structure or name viewUsers. That negates a large part of the value of views IMHO.
I once used "Dude" for the User table - same short number of characters, no conflict with keywords, still a reference to a generic human. If I weren't concerned about the stuffy heads that might see the code, I would have kept it that way.
As others have mentioned here, conventions should be a tool for adding to the ease of use and readability. Not as a shackle or a club to torture developers.
That said, my personal preference is to use singular names for both tables and columns. This probably comes from my programming background. Class names are generally singular unless they are some sort of collection. In my mind I am storing or reading individual records in the table in question, so singular makes sense to me.
This practice also allows me to reserve plural table names for those that store many-to-many relationships between my objects.
I try to avoid reserved words in my table and column names, as well. In the case in question here it makes more sense to go counter to the singular convention for Users to avoid the need to encapsulate a table that uses the reserved word of User.
I like using prefixes in a limited manner (tbl for table names, sp_ for proc names, etc), though many believe this adds clutter. I also prefer CamelBack names to underscores because I always end up hitting the + instead of _ when typing the name. Many others disagree.
Remember that the most important factor in your convention is that it make sense to the people interacting with the database in question. There is no "One Ring to Rule Them All" when it comes to naming conventions.
This may be a bit redundant, but I would suggest being cautious. Not necessarily that it's a bad thing to rename tables, but standardization is just that; a standard -- this database may already be "standardized", however badly :) -- I would suggest consistency to be a better goal given that this database already exists and presumably it consists of more than just 2 tables.
Unless you can standardize the entire database, or at least are planning to work towards that end, I suspect that table names are just the tip of the iceberg and concentrating on the task at hand, enduring the pain of poorly named objects, may be in your best interest --
Practical consistency sometimes is the best standard... :)
IMO using brackets is technically the safest approach, though it is a bit cumbersome. IMO it's 6 of one, half-a-dozen of the other, and your solution really just boils down to personal/team preference.
My take is in semantics depending on how you define your container. For example, A "bag of apples" or simply "apples" or an "apple bag" or "apple".
Example: a "college" table can contain 0 or more colleges a table of "colleges" can contain 0 or more collegues
a "student" table can contain 0 or more students
a table of "students" can contain 0 or more students.
My conclusion is that either is fine but you have to define how you (or people interacting with it) are going to approach when referring to the tables; "a x table" or a "table of xs"
I think using the singular is what we were taught in university. But at the same time you could argue that unlike in object oriented programming, a table is not an instance of its records.
I think I'm tipping in favour of the singular at the moment because of plural irregularities in English. In German it's even worse due to no consistent plural forms - sometimes you cannot tell if a word is plural or not without the specifying article in front of it (der/die/das). And in Chinese languages there are no plural forms anyway.
I always thought that was a dumb convention. I use plural table names.
(I believe the rational behind that policy is that it make it easier for ORM code generators to produce object & collection classes, since it is easier to produce a plural name from a singular name than vice-versa)
I did not see this clearly articulated in any of the previous answers. Many programmers have no formal definition in mind when working with tables. We often communicate intuitively in terms of of "records" or "rows". However, with some exceptions for denormalized relations, tables are usually designed so that the relation between the non-key attributes and the key constitutes a set theoretic function.
A function can be defined as a subset of a cross-product between two sets, in which each element of the set of keys occurs at most once in the mapping. Hence the terminology arising from from that perspective tends to be singular. One sees the same singular (or at least, non-plural) convention across other mathematical and computational theories involving functions (algebra and lambda calculus for instance).
发布评论
评论（30）
我有同样的问题，阅读完这里的所有答案后，我肯定会选择SINGULAR，原因：
原因 1（概念）。 你可以把装苹果的袋子想象成“AppleBag”，无论是装0个、1个还是一百万个苹果，它总是同一个袋子。 表就是容器，表名必须描述它包含什么，而不是它包含多少数据。 另外，复数概念更多的是口语中的一个（实际上是判断是否有一个或多个）。原因2。 （方便）。 使用单数名称比使用复数名称更容易。 对象可以有不规则的复数或根本不是复数，但总是有单数（除了新闻等少数例外）。
原因 3。 （美学和秩序）。 特别是在主从场景中，这读起来更好，按名称对齐更好，并且具有更多逻辑顺序（主第一，详细第二）：
相比：
原因 4< /strong>（简单）。 将所有这些放在一起，表名，主键，关系，实体类......最好只知道一个名称（单数）而不是两个（单数类，复数表，单数字段，单复数主从...... .)
CustomerCustomer.CustomerIDCustomerAddresspublic Class Customer {...}从客户中选择，其中CustomerID = 100一旦您知道您正在与“客户”打交道，您就可以确定您将使用相同的词来满足所有数据库交互需求。
原因 5。 （全球化）。 世界变得越来越小，你可能有一个不同国籍的团队，并不是每个人都以英语为母语。 对于非英语母语程序员来说，更容易想到“存储库”而不是“存储库”，或者“状态”而不是“状态”。 使用单一名称可以减少由拼写错误引起的错误，不必考虑“是 Child 还是 Children？”，从而节省时间，从而提高工作效率。
原因 6。 （为什么不？）。 它甚至可以节省您的书写时间，节省您的磁盘空间，甚至可以让您的电脑键盘使用寿命更长！
SELECT Customer.CustomerName FROM Customer WHERE Customer.CustomerID = 100SELECT Customers.CustomerName FROM Customers WHERE Customers.CustomerID = 103您已保存 3 个字母、3 个字节、3 个额外键盘点击:)
最后，你可以用保留名称来命名那些混乱的人，例如：
或者使用臭名昭著的方括号 [User]
I had same question, and after reading all answers here I definitely stay with SINGULAR, reasons:
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).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).
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):
Compared to:
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...)
CustomerCustomer.CustomerIDCustomerAddresspublic Class Customer {...}SELECT FROM Customer WHERE CustomerID = 100Once 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.
Reason 6. (Why not?). It can even save you writing time, save you disk space, and even make your computer keyboard last longer!
SELECT Customer.CustomerName FROM Customer WHERE Customer.CustomerID = 100SELECT Customers.CustomerName FROM Customers WHERE Customers.CustomerID = 103You have saved 3 letters, 3 bytes, 3 extra keyboard hits :)
And finally, you can name those ones messing up with reserved names like:
Or use the infamous square brackets [User]
我更喜欢使用未变形名词，它在英语中恰好是单数。
改变表名称的数字会导致拼写问题（正如许多其他答案所示），但由于表通常包含多行而选择这样做在语义上也充满了漏洞。 如果我们考虑一种根据大小写改变名词的语言（就像大多数语言一样），这一点就更明显了：
既然我们通常对行做一些事情，为什么不把名字放在宾格中呢？ 如果我们有一个表，写入的次数多于读取的次数，为什么不将名称放在与格中呢？ 这是一个包含某些内容的表格，为什么不使用所有格呢？ 我们不会这样做，因为表被定义为一个抽象容器，无论其状态或用途如何，它都存在。 在没有精确和绝对语义原因的情况下对名词进行变形是胡言乱语。
使用未变形的名词简单、合乎逻辑、规则且与语言无关。
I prefer to use the uninflected noun, 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 of something, 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.
如果您使用或将来会使用对象关系映射工具，我建议您Singular。
一些工具（例如 LLBLGen）可以自动更正复数名称（例如“Users”为“User”），而无需更改表名称本身。 为什么这很重要？ 因为当它被映射时，你希望它看起来像 User.Name 而不是 Users.Name 或更糟糕的是我的一些旧数据库表命名为 tblUsers.strName 这在代码中令人困惑。
我的新经验法则是判断它转换成对象后的外观。
我发现一个不符合我使用的新命名的表是 UsersInRoles。 但总会有少数例外，即使在这种情况下，它看起来也很好，如 UsersInRoles.Username。
If you use Object Relational Mapping tools or will in the future I suggest 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.
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.
就“标准”而言，其他人给出了相当好的答案，但我只是想添加这一点......“用户”（或“用户”）实际上是否有可能并不是表中保存的数据的完整描述？ 并不是说您应该对表名称和特殊性过于着迷，但也许像“Widget_Users”（其中“Widget”是您的应用程序或网站的名称）之类的名称会更合适。
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.
什么约定要求表具有单一名称？ 我一直以为是复数名字。
用户将添加到“用户”表中。
本网站同意：
http://vyaskn.tripod.com/object_naming.htm#Tables
本网站不同意 (但我不同意）：
http://justinsomnia.org/writings/naming_conventions.html
正如其他人提到的：这些只是指导方针。 选择一个适合您和您的公司/项目的惯例并坚持下去。 在单数和复数之间切换，或者有时缩写词有时不缩写词更让人恼火。
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
This site disagrees (but I disagree with it):
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.
举个简单的例子：
vs.
后者的 SQL 听起来比前者更奇怪。
我投票给单数。
How about this as a simple example:
vs.
The SQL in the latter is stranger sounding than the former.
I vote for singular.
我坚信，在实体关系图中，实体应该用单一名称来反映，类似于单一的类名称。 一旦实例化，名称就会反映其实例。 因此，对于数据库来说，当制成表（实体或记录的集合）时，实体是复数的。 实体，User做成表Users。 我同意其他人的建议，他们建议可以将 User 名称改进为 Employee 或更适合您的场景。
这在 SQL 语句中更有意义，因为您是从一组记录中进行选择，如果表名是单数，则读起来不太好。
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.
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.
恕我直言，表名称应该是复数，例如Customers。
如果类名称映射到 Customers 表中的一行，则类名称应该是单数，例如 Customer。
IMHO, table names should be plural like Customers.
Class names should be singular like Customer if it maps to a row in the Customers table.
我坚持使用单数作为表名和任何编程实体。
原因？ 事实上，英语中有不规则的复数形式，例如mouse ⇒ mouse和sheep ⇒sheep。 然后，如果我需要一个集合，我只需使用老鼠或绵羊，然后继续。
它确实有助于突出多样性，而且我可以轻松地以编程方式确定事物的集合会是什么样子。
所以，我的规则是：一切都是单一的，每个事物的集合都是单一的，并附加一个s。 对 ORM 也有帮助。
I stick with singular for table names and any programming entity.
The reason? The fact that there are irregular plurals in English like mouse ⇒ mice and sheep ⇒ sheep. Then, if I need a collection, i just use mouses or sheeps, and move on.
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 s appended. Helps with ORMs too.
单数。 我不相信任何涉及哪个最合乎逻辑的论点——每个人都认为他自己的偏好是最合乎逻辑的。 不管你做什么都是一团糟，只要选择一个惯例并坚持下去即可。 我们正在尝试将语法和语义高度不规则的语言（正常口语和书面语言）映射到具有非常特定语义的高度规则（SQL）语法。
我的主要论点是，我不认为表格是一组，而是关系。
因此，
AppUser关系告诉哪些实体是AppUsers。AppUserGroup关系告诉我哪些实体是AppUserGroupsAppUser_AppUserGroup关系告诉我AppUsers和AppUserGroups 如何是相关的。AppUserGroup_AppUserGroup关系告诉我AppUserGroups和AppUserGroups是如何相关的（即组的组成员）。换句话说，当我想到实体以及它们如何相关时，我想到的是单数关系，但是当然，当我想到集合或集合中的实体时，集合或集合是复数的。
那么，在我的代码和数据库模式中，我使用单数。 在文本描述中，我最终使用复数来增加可读性 - 然后使用字体等来区分表/关系名称和复数。
我喜欢将其视为杂乱但系统的——这样我想要表达的关系总是有一个系统生成的名称，这对我来说非常重要。
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.
My main argument is that I don't think of the tables as a set but as relations.
So, the
AppUserrelation tells which entities areAppUsers.The
AppUserGrouprelation tells me which entities areAppUserGroupsThe
AppUser_AppUserGrouprelation tells me how theAppUsersandAppUserGroupsare related.The
AppUserGroup_AppUserGrouprelation tells me howAppUserGroupsandAppUserGroupsare related (i.e. groups member of groups).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.
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.
我也会选择复数，并且由于前面提到的用户困境，我们确实采用了方括号方法。
我们这样做是为了在数据库架构和应用程序架构之间提供统一性，并基本理解为Users表是User值的集合，就像Users 代码工件中的集合是User对象的集合。
让我们的数据团队和开发人员使用相同的概念语言（尽管对象名称并不总是相同）可以更轻松地在他们之间传达想法。
I also would go with plurals, and with the aforementioned Users dilemma, we do take the square bracketing approach.
We do this to provide uniformity between both database architecture and application architecture, with the underlying understanding that the Users table is a collection of User values as much as a Users collection in a code artifact is a collection of User objects.
Having our data team and our developers speaking the same conceptual language (although not always the same object names) makes it easier to convey ideas between them.
我个人更喜欢使用复数名称来表示一个集合，这对我的关系思维来说“听起来”更好。
此时此刻，我正在使用单一名称来为我的公司定义数据模型，因为大多数工作人员对此感到更舒服。
有时你只需要让每个人的生活变得更轻松，而不是强加你的个人喜好。
（这就是我在这个帖子中的结局，以确认命名表的“最佳实践”应该是什么）
在阅读了这个帖子中的所有争论后，我得出了一个结论：
我喜欢我的蜂蜜煎饼，无论如何每个人最喜欢的味道是什么。 但如果我为别人做饭，我会尽力为他们提供他们喜欢的东西。
I personaly prefer to use plural names to represent a set, it just "sounds" better to my relational mind.
At this exact moment i am using singular names to define a data model for my company, because most of the people at work feel more confortable with it.
Sometimes you just have to make life easier to everyone instead of imposing your personal preferences.
(that's how i ended up in this thread, to get a confirmation on what should be the "best practice" for naming tables)
After reading all the arguing in this thread, i reached one conclusion:
I like my pancakes with honey, no matter what everybody's favorite flavour is. But if i am cooking for other people, i will try to serve them something they like.
实际上我一直认为使用复数表名是流行的惯例。 到目前为止，我一直使用复数。
我可以理解单数表名的论点，但对我来说复数更有意义。 表名通常描述表包含的内容。 在规范化数据库中，每个表都包含特定的数据集。 每一行都是一个实体，表中包含许多实体。 因此表名的复数形式。
汽车表的名称为cars，每行都是一辆汽车。 我承认以
table.field方式指定表和字段是最佳实践，并且使用单一表名更具可读性。 然而，在下面的两个例子中，前者更有意义：老实说，我将重新考虑我在此事上的立场，并且我将依赖我正在开发的组织所使用的实际约定。 但是，我认为根据我的个人惯例，我会坚持使用复数表名称。 对我来说这更有意义。
I've actually always thought it was popular convention to use plural table names. Up until this point I've always used plural.
I can understand the argument for singular table names, but to me plural makes more sense. A table name usually describes what the table contains. In a normalized database, each table contains specific sets of data. Each row is an entity and the table contains many entities. Thus the plural form for the table name.
A table of cars would have the name cars and each row is a car. I'll admit that specifying the table along with the field in a
table.fieldmanner is the best practice and that having singular table names is more readable. However in the following two examples, the former makes more sense:Honestly, I will be rethinking my position on the matter, and I would rely on the actual conventions used by the organization I'm developing for. However, I think for my personal conventions, I'll stick with plural table names. To me it makes more sense.
单数。 我将包含一堆用户行表示对象的数组称为“用户”，但该表是“用户表”。 在我看来，认为表只是它所包含的行集的想法是错误的； 表是元数据，行集分层附加到表，而不是表本身。
当然，我一直在使用 ORM，而且用复数表名编写的 ORM 代码看起来很愚蠢，这很有帮助。
Singular. I'd call an array containing a bunch of user row representation objects 'users', but the table is 'the user table'. Thinking of the table as being nothing but the set of the rows it contains is wrong, IMO; the table is the metadata, and the set of rows is hierarchically attached to the table, it is not the table itself.
I use ORMs all the time, of course, and it helps that ORM code written with plural table names looks stupid.
我不喜欢复数表名，因为英语中的一些名词是不可数的（水、汤、现金），或者当你使其可数时含义会发生变化（鸡与鸡；肉与鸟）。
我也不喜欢使用表名或列名的缩写，因为这样做会给已经很陡峭的学习曲线增加额外的坡度。
具有讽刺意味的是，我可能会将
User作为一个例外，并将其称为Users，因为USER (Transac-SQL)，因为如果不需要的话，我也不喜欢在表周围使用括号。我还喜欢将所有 ID 列命名为
Id，而不是ChickenId或ChickensId（多个人对此做什么？）。所有这一切都是因为我对数据库系统没有适当的尊重，我只是重新应用来自 OO 命名约定的一招小马知识，例如 Java 出于习惯和懒惰。 我希望 IDE 对复杂的 SQL 有更好的支持。
I don't like plural table names because some nouns in English are not countable (water, soup, cash) or the meaning changes when you make it countable (chicken vs a chicken; meat vs bird).
I also dislike using abbreviations for table name or column name because doing so adds extra slope to the already steep learning curve.
Ironically, I might make
Useran exception and call itUsersbecause of USER (Transac-SQL), because I too don't like using brackets around tables if I don't have to.I also like to name all the ID columns as
Id, notChickenIdorChickensId(what do plural guys do about this?).All this is because I don't have proper respect for the database systems, I am just reapplying one-trick-pony knowledge from OO naming conventions like Java's out of habit and laziness. I wish there were better IDE support for complicated SQL.
如果我们查看
MS SQL Server系统表，就会发现 Microsoft 指定的它们的名称是复数。Oracle 的系统表以
单数命名。 尽管其中一些是复数。Oracle 建议用户定义的表名称使用复数形式。
他们推荐一件事而遵循另一件事是没有多大意义的。
这两个软件巨头的架构师使用不同的约定来命名他们的表，也没有多大意义……毕竟，这些人是什么……博士学位？
我记得在学术界，这个建议是单一的。
例如，当我们说：
也许 b/c 每个
ID都是从特定的单行中选择的......？If we look at
MS SQL Server'ssystem tables, their names as assigned by Microsoft are inplural.The Oracle's system tables are named in
singular. Although a few of them are plural.Oracle recommends plural for user-defined table names.
That doesn't make much sense that they recommend one thing and follow another.
That the architects at these two software giants have named their tables using different conventions, doesn't make much sense either... After all, what are these guys ... PhD's?
I do remember in academia, the recommendation was singular.
For example, when we say:
maybe b/c each
IDis selected from a particular single row ...?表：复数
型号: 单数
控制器：复数
无论如何，这就是我的看法。
Tables: plural
Models: singular
Controllers: plural
That's my take on it anyway.
我们运行类似的标准，在编写脚本时，我们要求在名称周围使用 [ ]，并在适当的情况下使用模式限定符 - 主要是它可以对冲您对未来 SQL 语法抢夺名称的赌注。
这在过去拯救了我们的灵魂 - 我们的一些数据库系统从 SQL 6.0 到 SQL 2005 已经运行了 10 多年 - 远远超过了它们的预期寿命。
We run similar standards, when scripting we demand [ ] around names, and where appropriate schema qualifiers - primarily it hedges your bets against future name grabs by the SQL syntax.
This has saved our souls in the past - some of our database systems have run 10+ years from SQL 6.0 through SQL 2005 - way past their intended lifespans.
服务器本身的系统
表/视图（SYSCAT.TABLES、dbo.sysindexes、ALL_TABLES、information_schema.columns等）几乎总是复数。 我想为了保持一致性，我会跟随他们的领导。The system
tables/viewsof the server itself (SYSCAT.TABLES,dbo.sysindexes,ALL_TABLES,information_schema.columns, etc.) are almost always plural. I guess for the sake of consistency I'd follow their lead.我一直使用单数只是因为那是我被教导的。 然而，在最近创建一个新模式时，很长一段时间以来我第一次主动决定维持这个约定，只是因为......它更短。 对我来说，在每个表名末尾添加“s”就像在每个表名前面添加“tbl_”一样无用。
I've always used singular simply because that's what I was taught. However, while creating a new schema recently, for the first time in a long time, I actively decided to maintain this convention simply because... it's shorter. Adding an 's' to the end of every table name seems as useless to me as adding 'tbl_' in front of every one.
我是单数表名的粉丝，因为它们使我使用 CASE 语法的 ER 图更易于阅读，但通过阅读这些回复，我感觉它从未流行起来？ 我个人很喜欢它。 有一个很好的概述，其中包含示例，说明当您使用单数表名称、向关系添加动作动词以及为每个关系形成良好的句子时，模型的可读性如何。 对于一个包含 20 个表的数据库来说，这有点大材小用，但是如果您的数据库包含数百个表和复杂的设计，那么如果没有良好的可读图表，您的开发人员将如何理解它呢？
http://www.aisintl.com/case/method.html
至于前缀表和观点我绝对讨厌这种做法。 在向某人提供可能是错误的信息之前，不要向他们提供任何信息。 浏览数据库中的对象的任何人都可以很容易地从视图中区分表，但是如果我有一个名为 tblUsers 的表，出于某种原因，我决定将来将其重组为两个表，并使用一个视图将它们统一起来，以免破坏旧代码我现在有一个名为 tblUsers 的视图。 此时，我只剩下两个没有吸引力的选项，留下一个以 tbl 前缀命名的视图，这可能会让一些开发人员感到困惑，或者强制重写另一层（中间层或应用程序）以引用我的新结构或名称 viewUsers。 恕我直言，这否定了视图的很大一部分价值。
I am a fan of singular table names as they make my ER diagrams using CASE syntax easier to read, but by reading these responses I'm getting the feeling it never caught on very well? I personally love it. There is a good overview with examples of how readable your models can be when you use singular table names, add action verbs to your relationships and form good sentences for every relationships. It's all a bit of overkill for a 20 table database but if you have a DB with hundreds of tables and a complex design how will your developers ever understand it without a good readable diagram?
http://www.aisintl.com/case/method.html
As for prefixing tables and views I absolutely hate that practice. Give a person no information at all before giving them possibly bad information. Anyone browsing a db for objects can quite easily tell a table from a view, but if I have a table named tblUsers that for some reason I decide to restructure in the future into two tables, with a view unifying them to keep from breaking old code I now have a view named tblUsers. At this point I am left with two unappealing options, leave a view named with a tbl prefix which may confuse some developers, or force another layer, either middle tier or application to be rewritten to reference my new structure or name viewUsers. That negates a large part of the value of views IMHO.
我曾经使用“Dude”作为用户表 - 相同的短字符数，与关键字没有冲突，仍然是对通用人类的引用。 如果我不担心那些闷闷不乐的人可能会看到代码，我就会保持这种方式。
I once used "Dude" for the User table - same short number of characters, no conflict with keywords, still a reference to a generic human. If I weren't concerned about the stuffy heads that might see the code, I would have kept it that way.
正如其他人在这里提到的，约定应该是一种增加易用性和可读性的工具。 不是作为拷问开发者的枷锁、棍棒。
也就是说，我个人倾向于对表和列使用单一名称。 这可能来自我的编程背景。 类名通常是单数，除非它们是某种集合。 在我看来，我正在存储或读取相关表中的单个记录，因此单数对我来说是有意义的。
这种做法还允许我为那些存储对象之间多对多关系的表保留复数表名称。
我也尽量避免在表名和列名中使用保留字。 在这里讨论的情况下，与 Users 的单数约定相反更有意义，以避免需要封装使用 User 保留字的表。
我喜欢以有限的方式使用前缀（tbl 表示表名，sp_ 表示过程名称等），尽管许多人认为这会增加混乱。 我也更喜欢 CamelBack 名称而不是下划线，因为在输入名称时我总是点击 + 而不是 _。 许多其他人不同意。
这是命名约定指南的另一个很好的链接：http://www.xaprb.com/blog/2008/10/26/the-power-of-a-good-sql-naming-convention/
记住最重要的因素按照您的惯例，这对于与相关数据库交互的人来说是有意义的。 在命名约定方面，不存在“一环统治一切”的说法。
As others have mentioned here, conventions should be a tool for adding to the ease of use and readability. Not as a shackle or a club to torture developers.
That said, my personal preference is to use singular names for both tables and columns. This probably comes from my programming background. Class names are generally singular unless they are some sort of collection. In my mind I am storing or reading individual records in the table in question, so singular makes sense to me.
This practice also allows me to reserve plural table names for those that store many-to-many relationships between my objects.
I try to avoid reserved words in my table and column names, as well. In the case in question here it makes more sense to go counter to the singular convention for Users to avoid the need to encapsulate a table that uses the reserved word of User.
I like using prefixes in a limited manner (tbl for table names, sp_ for proc names, etc), though many believe this adds clutter. I also prefer CamelBack names to underscores because I always end up hitting the + instead of _ when typing the name. Many others disagree.
Here is another good link for naming convention guidelines: http://www.xaprb.com/blog/2008/10/26/the-power-of-a-good-sql-naming-convention/
Remember that the most important factor in your convention is that it make sense to the people interacting with the database in question. There is no "One Ring to Rule Them All" when it comes to naming conventions.
这可能有点多余，但我建议谨慎行事。 重命名表不一定是坏事，但标准化就是这样； 一个标准——这个数据库可能已经是“标准化的”，尽管很糟糕:)——我建议一致性是一个更好的目标，因为这个数据库已经存在，并且可能它包含的不仅仅是两个表。
除非您可以标准化整个数据库，或者至少计划为此目的而努力，否则我怀疑表名称只是冰山一角，并且专注于手头的任务，忍受命名不当的对象的痛苦，可能会在你的最大利益 -
实际一致性有时是最好的标准......:)
my2cents ---
This may be a bit redundant, but I would suggest being cautious. Not necessarily that it's a bad thing to rename tables, but standardization is just that; a standard -- this database may already be "standardized", however badly :) -- I would suggest consistency to be a better goal given that this database already exists and presumably it consists of more than just 2 tables.
Unless you can standardize the entire database, or at least are planning to work towards that end, I suspect that table names are just the tip of the iceberg and concentrating on the task at hand, enduring the pain of poorly named objects, may be in your best interest --
Practical consistency sometimes is the best standard... :)
my2cents ---
可能的替代方案：
IMO 使用括号在技术上是最安全的方法，尽管它有点麻烦。 IMO 是其中的 6 个，其他的六个，而您的解决方案实际上可以归结为个人/团队的偏好。
Possible alternatives:
IMO using brackets is technically the safest approach, though it is a bit cumbersome. IMO it's 6 of one, half-a-dozen of the other, and your solution really just boils down to personal/team preference.
我的看法是语义取决于您如何定义容器。 例如，“一袋苹果”或简称“苹果”或“苹果袋”或“苹果”。
例子：
“学院”表可以包含 0 个或多个学院
“学院”表可以包含 0 个或多个同事。
我的结论是，两者都可以，但您必须定义在引用这些表时您（或与其交互的人）将如何处理； “ax 表”或“xs 表”
My take is in semantics depending on how you define your container. For example, A "bag of apples" or simply "apples" or an "apple bag" or "apple".
Example:
a "college" table can contain 0 or more colleges
a table of "colleges" can contain 0 or more collegues
My conclusion is that either is fine but you have to define how you (or people interacting with it) are going to approach when referring to the tables; "a x table" or a "table of xs"
我认为使用单数是我们在大学里学到的。 但同时您可能会争辩说，与面向对象编程不同，表不是其记录的实例。
我认为由于英语中复数的不规则性，我现在倾向于使用单数。 在德语中，情况更糟，因为没有一致的复数形式 - 有时如果没有前面指定的冠词（der/die/das），你无法判断一个单词是否是复数。 无论如何，汉语中没有复数形式。
I think using the singular is what we were taught in university. But at the same time you could argue that unlike in object oriented programming, a table is not an instance of its records.
I think I'm tipping in favour of the singular at the moment because of plural irregularities in English. In German it's even worse due to no consistent plural forms - sometimes you cannot tell if a word is plural or not without the specifying article in front of it (der/die/das). And in Chinese languages there are no plural forms anyway.
我只使用拼写相同的名词作为表名，无论是单数还是复数：
moose
鱼
鹿
飞机
你
裤子
短裤
眼镜
剪刀
物种
后代
I only use nouns for my table names that are spelled the same, whether singular or plural:
moose
fish
deer
aircraft
you
pants
shorts
eyeglasses
scissors
species
offspring
我一直认为这是一个愚蠢的惯例。 我使用复数表名。
（我相信该政策背后的合理性是，它使 ORM 代码生成器更容易生成对象和集合类，因为从单数名称生成复数名称比反之亦然更容易）
I always thought that was a dumb convention. I use plural table names.
(I believe the rational behind that policy is that it make it easier for ORM code generators to produce object & collection classes, since it is easier to produce a plural name from a singular name than vice-versa)
我在之前的任何答案中都没有看到明确阐述这一点。 许多程序员在使用表时并没有想到正式的定义。 我们经常用“记录”或“行”来直观地进行交流。 然而，除了非规范化关系的一些例外之外，表通常被设计为使得非键属性和键之间的关系构成集合论函数。
函数可以定义为两个集合之间叉积的子集，其中键集合的每个元素在映射中最多出现一次。 因此，从这个角度产生的术语往往是单一的。 人们在涉及函数（例如代数和 lambda 演算）的其他数学和计算理论中看到了相同的单数（或至少是非复数）约定。
I did not see this clearly articulated in any of the previous answers. Many programmers have no formal definition in mind when working with tables. We often communicate intuitively in terms of of "records" or "rows". However, with some exceptions for denormalized relations, tables are usually designed so that the relation between the non-key attributes and the key constitutes a set theoretic function.
A function can be defined as a subset of a cross-product between two sets, in which each element of the set of keys occurs at most once in the mapping. Hence the terminology arising from from that perspective tends to be singular. One sees the same singular (or at least, non-plural) convention across other mathematical and computational theories involving functions (algebra and lambda calculus for instance).