我通过将表命名为“雇员”（实际上是“雇员”）来解决同样的问题。我尽量避免与可能保留的单词发生冲突。即使是“用户”对我来说也很近。

我是单数表名的粉丝，因为它们使用CASE语法使我的ER图更容易阅读，但通过阅读这些响应，我感到它从未很好地被理解？我个人很喜欢它。这里有一个很好的概述，举例说明当你使用单数表名，在你的关系中添加动作动词，并为每一种关系形成好句子时，你的模型是多么可读。对于一个20表的数据库来说，这有点过分了，但是如果您有一个包含数百个表的数据库，并且设计复杂，如果没有一个可读性好的图表，您的开发人员将如何理解它？

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

至于表和视图的前缀，我绝对讨厌这种做法。在给一个人提供可能不好的信息之前，不要给他任何信息。任何浏览数据库查找对象的人都可以很容易地将表与视图区分开来，但如果我有一个名为tblUsers的表，出于某种原因，我决定在将来将其重组为两个表，并使用一个视图统一它们，以防破坏旧代码，那么我现在有一个名称为tblUser的视图。此时，我只剩下两个没有吸引力的选项：留下一个带有tbl前缀的视图，这可能会让一些开发人员感到困惑，或者强制重写另一个层（中间层或应用程序），以引用我的新结构或名称viewUsers。这否定了IMHO视图的大部分价值。

正如其他人在这里提到的，约定应该是一种工具，可以增加易用性和可读性。不是用来折磨开发者的枷锁或俱乐部。

也就是说，我个人倾向于对表和列使用单数名称。这可能来自我的编程背景。类名通常是单数，除非它们是某种集合。在我的脑海中，我正在存储或读取相关表中的单个记录，所以单数对我来说是有意义的。

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

我也尽量避免在表和列名中使用保留字。在这里所讨论的情况下，违背用户的单一约定更有意义，以避免需要封装使用User的保留字的表。

我喜欢以有限的方式使用前缀（tbl表示表名，sp_表示进程名等），尽管许多人认为这会增加混乱。与下划线相比，我更喜欢CamelBack名称，因为我在键入名称时总是按+而不是_。许多人不同意。

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

请记住，您的惯例中最重要的因素是，它对与所讨论的数据库交互的人来说是有意义的。在命名惯例方面，没有“一个戒指来统治所有人”。

举个简单的例子：

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

vs.

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

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

我投票支持单数。

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

用户将添加到“用户”表中。

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

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

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

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

原因是什么？事实上，英语中有不规则的复数形式，如mouse⇒ 老鼠和绵羊⇒ 羊然后，如果我需要收集，我只需要使用老鼠或绵羊，然后继续。

这确实有助于多元性脱颖而出，而且我可以通过编程轻松地确定这些东西的集合是什么样子的。

所以，我的规则是：所有事物都是单数，所有事物的集合都是单数的，并加上s。也有助于ORM。