学术界认为，表名应该是存储其属性的实体的单数。
我不喜欢任何需要在名称周围加方括号的T-SQL，但我已经将一个Users表重命名为单数，这永远意味着使用该表的人有时不得不使用括号。
我的直觉是，保持单数更正确，但我的直觉也是，括号表示不需要的东西，比如列名中有空格等。
我该留下还是该走？
当前回答
如果你去那里会有麻烦，但如果你留下来，麻烦就会加倍。
我宁愿违背一些假定的非复数命名惯例，也不愿用可能是保留词的名称来命名我的表。
其他回答
我有同样的问题，在阅读了这里的所有答案后，我肯定会选择SINGULAR，原因如下：
原因1（概念）。你可以把装苹果的袋子想象成“苹果袋”，不管是装0个、1个还是100万个苹果，都是同一个袋子。表只是容器，表名必须描述它包含的内容，而不是它包含多少数据。此外，复数概念更多地是关于口语的一个（实际上是为了确定是否有一个或多个）。
原因2。（方便）。用单数名字比用复数名字更容易。对象可以有不规则的复数形式，也可以完全没有复数形式，但总是有单数形式（新闻等少数例外）。
顾客顺序使用者地位消息
原因3。（美学和秩序）。特别是在主细节场景中，这读起来更好，按名称排列更好，逻辑顺序更高（主细节优先，细节第二）：
1.订单2.订单详情
对比：
1.订单详情2.订单
原因4（简单）。把所有这些放在一起，表名、主键、关系、实体类。。。最好只知道一个名称（单数），而不是两个名称（单一类、复数表、单数字段、单数复数主细节…）
顾客客户.CustomerID客户地址公共类客户｛…｝从客户选择CustomerID=100
一旦你知道你是在和“客户”打交道，你就可以确定你会对所有的数据库交互需求使用同一个词。
原因5。（全球化）。世界越来越小，你可能有一个不同国籍的团队，但不是每个人都以英语为母语。对于非英语母语的程序员来说，想到“存储库”比想到“存储”更容易，或者想到“状态”而不是“状态”。使用单数名称可以减少因拼写错误导致的错误，不必思考“是孩子还是孩子？”，从而节省时间，从而提高生产力。
原因6。（为什么不呢？）。它甚至可以节省你的写作时间，节省你的磁盘空间，甚至让你的电脑键盘更耐用！
选择客户.CustomerName FROM Customer WHERE Customer.CustomerID=100选择Customers.CustomerName FROM Customers WHERE Customers.CustomerID=103
您已保存了3个字母、3个字节和3次额外的键盘点击：）
最后，你可以说出那些用保留名搞乱的名字，比如：
用户>LogiUser、AppUser、SystemUser、CMSUser，。。。
或者使用臭名昭著的方括号[User]
我们运行类似的标准，在编写脚本时，我们要求[]围绕名称，并在适当的情况下使用模式限定符-主要是为了防止SQL语法将来夺取名称。
SELECT [Name] FROM [dbo].[Customer] WHERE [Location] = 'WA'
这在过去拯救了我们的灵魂——我们的一些数据库系统从SQL 6.0到SQL 2005已经运行了10多年——远远超过了预期寿命。
什么约定要求表具有单数名称？我一直以为是复数。
用户将添加到“用户”表中。
本网站同意：http://vyaskn.tripod.com/object_naming.htm#Tables
本网站不同意（但我不同意）：http://justinsomnia.org/writings/naming_conventions.html
正如其他人所提到的：这些只是指导方针。选择一个适合你和你的公司/项目的惯例，并坚持下去。在单数和复数之间切换，或者有时缩写词，有时不缩写词，这会让人更加恼火。
可能的替代方案：
重命名表SystemUser使用括号保留多个表名。
IMO使用括号从技术上来说是最安全的方法，尽管它有点麻烦。IMO是一个6个，另一个6打，您的解决方案实际上只是归结为个人/团队偏好。
我一直认为那是一个愚蠢的惯例。我使用多个表名。
（我相信这一策略背后的原因是，它使ORM代码生成器更容易生成对象和集合类，因为从单数名称生成复数名称比从单数名称中生成复数名称更容易）
