服务器本身的系统表/视图（SYSCAT.tables、dbo.sysindexes、ALL_tables、information_schema.columns等）几乎总是多个。我想为了保持一致，我会追随他们的脚步。

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

（我相信这一策略背后的原因是，它使ORM代码生成器更容易生成对象和集合类，因为从单数名称生成复数名称比从单数名称中生成复数名称更容易）

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

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

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

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

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

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

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

举个简单的例子：

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

vs.

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

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

我投票支持单数。

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

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

你到底为什么要在一个对象名称的末尾加一个“s”？将“s”放在对象名称的末尾，表示什么意思？

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

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

表是一个DB对象，与其他对象没有区别。

保存3个字符只会使意思清晰。

红色；-）