表命名困境：单数与复数名称

学术界认为，表名应该是存储其属性的实体的单数。

我不喜欢任何需要在名称周围加方括号的T-SQL，但我已经将一个Users表重命名为单数，这永远意味着使用该表的人有时不得不使用括号。

我的直觉是，保持单数更正确，但我的直觉也是，括号表示不需要的东西，比如列名中有空格等。

我该留下还是该走？

当前回答

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

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

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

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

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

其他回答

举个简单的例子：

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

vs.

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

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

我投票支持单数。

两个网站都有不同的论文，我认为你只需要选择你的一方。就我个人而言，我更喜欢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演算）中，人们可以看到相同的单数（或至少是非复数）约定。

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

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

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

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

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

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

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

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

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

推荐文章