我们运行类似的标准，在编写脚本时，我们要求[]围绕名称，并在适当的情况下使用模式限定符-主要是为了防止SQL语法将来夺取名称。

SELECT [Name] FROM [dbo].[Customer] WHERE [Location] = 'WA'

这在过去拯救了我们的灵魂——我们的一些数据库系统从SQL 6.0到SQL 2005已经运行了10多年——远远超过了预期寿命。

两个网站都有不同的论文，我认为你只需要选择你的一方。就我个人而言，我更喜欢Plular来命名表，当然，单数来命名列。

我喜欢你怎么读这个：

SELECT CustomerName FROM Customers WHERE CustomerID = 100;

的确，我们有OOP，这很好，但大多数人仍然使用关系数据库，而不是对象数据库。关系数据库不需要遵循OOP概念。

另一个例子是，您有一个表Teams，它保存了TeamID、TeamColor和PlayerID，并且对于一定数量的PlayerID将具有相同的TeamID和TeamColor。。。

该球员属于哪支球队？

SELECT * FROM Teams WHERE PlayerID = X

X队的所有球员？

SELECT * FROM Players INNER JOIN Teams ON Players.PlayerID = Teams.PlayerID WHERE Teams.TeamID = X

你觉得这一切都好吗？

无论如何，还可以看看W3Schools使用的命名约定：

http://www.w3schools.com/sql/sql_join_inner.asp

我在之前的任何回答中都没有看到这一点。许多程序员在处理表时没有正式的定义。我们经常以“记录”或“行”的形式直观地交流。然而，除了一些非规范化关系的例外，表通常被设计为使得非键属性和键之间的关系构成集合论函数。

函数可以定义为两个集合之间的叉积的子集，其中键集合的每个元素在映射中最多出现一次。因此，从这个角度产生的术语往往是单数。在涉及函数的其他数学和计算理论（例如代数和lambda演算）中，人们可以看到相同的单数（或至少是非复数）约定。

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

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

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

我认为使用单数是我们在大学里学到的。但同时，您可能会认为，与面向对象编程不同，表不是其记录的实例。

我想我现在倾向于单数，因为英语中的复数不规范。在德语中，由于没有一致的复数形式，情况更糟——有时，如果没有前面的指定冠词（der/die/das），你就无法判断一个单词是否为复数。无论如何，在汉语中没有复数形式。

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

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

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

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

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

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

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

红色；-）