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

【问题标题】：Table Naming Dilemma: Singular vs. Plural Names [closed]表命名困境：单数与复数名称
【发布时间】：2010-09-25 04:30:03
【问题描述】：

学术界认为表名应该是它们存储属性的实体的单数形式。

我不喜欢任何需要在名称周围加上方括号的 T-SQL，但我已将 Users 表重命名为单数，永远判刑那些使用该表的人有时必须使用方括号。

我的直觉是保持单数更正确，但我的直觉也是括号表示不受欢迎的内容，例如列名中带有空格等。

我应该留下，还是应该离开？

【问题讨论】：

我很惊讶更多的人没有说：这取决于单行代表什么。在单个数据库中，我可能有一个表，其行表示单个小部件，另一个与该表的一对多关系表示行表示许多小部件。不这样做会失去表现力。
我只是想在所有这些讨论中补充一点，请注意，表格的形状或形式与类不同。表是特定类型元素的集合，可以对各个属性进行排序、查询等。类是描述特定类型的属性和行为的框架。在 OO 编码术语中，表的关闭表示是对象的集合。（无论您使用什么 ORM）。这是迄今为止该主题上排名最高的谷歌答案，因此尽管问题已关闭，但该页面仍然有价值。
我会选择你正在工作的生态系统的常见做法。例如：在 Node.js 中，像 Bookshelf.js 或 Objection.js 这样的 ORM 主要基于“Knex.js”。在“Knex.js”文档中，您会找到复数形式的表名。所以我会在那个领域使用复数。来源：knexjs.org/#Schema-createTable
是的，我同意。有一个用户表并将其称为“AppUser”是有意义的，同时拥有一个适用于特定类型用户的规则表并将其称为“UserRules”也是有意义的
@Arindam "UserRule" 或 "UsersRule" 绝对不适合作为用户相关规则列表的名称。现在这是一个反对总是使用单数形式的有力论据！

标签： sql sql-server naming-conventions

【解决方案1】：

我有同样的问题，在阅读了这里的所有答案后，我肯定会选择 SINGULAR，原因：

原因 1（概念）。你可以把装苹果的袋子想象成“AppleBag”，不管是0个、1个还是100万个苹果，它总是同一个袋子。表就是这样，容器，表名必须描述它包含什么，而不是它包含多少数据。此外，复数概念更多的是关于口语的一种（实际上是确定是否存在一种或多种）。

原因 2。（方便）。使用单数名称比使用复数名称更容易出现。对象可以有不规则复数，也可以根本不复数，但总是有一个单数（除了少数例外，如 News）。

客户
订购
用户
状态
新闻

原因 3。（审美和秩序）。特别是在 master-detail 场景中，这读起来更好，按名称对齐更好，并且有更多的逻辑顺序（Master first, Detail second）：

1.订单
2.OrderDetail

相比：

1.订单详情
2.订单

原因 4（简单）。总而言之，表名称、主键、关系、实体类......最好只知道一个名称（单数）而不是两个（单数类、复数表、单数字段、单数-复数主-详细信息.. .)

Customer
Customer.CustomerID
CustomerAddress
public Class Customer {...}
SELECT FROM Customer WHERE CustomerID = 100

一旦您知道您正在与“客户”打交道，您就可以确定您将使用同一个词来满足您所有的数据库交互需求。

原因 5。（全球化）。世界越来越小，你可能有一个不同国籍的团队，并不是每个人都以英语为母语。对于非英语母语的程序员来说，想到“Repository”比想到“Repositories”或者“Status”而不是“Statuses”会更容易。使用单数名称可以减少由拼写错误引起的错误，不必考虑“是孩子还是孩子？”从而节省时间，从而提高工作效率。

原因 6。（为什么不？）。它甚至可以节省您的书写时间、节省磁盘空间，甚至让您的电脑键盘更耐用！

SELECT Customer.CustomerName FROM Customer WHERE Customer.CustomerID = 100
SELECT Customers.CustomerName FROM Customers WHERE Customers.CustomerID = 103

你已经保存了 3 个字母、3 个字节、3 个额外的键盘击键 :)

最后，您可以将那些与保留名称混淆的名称命名为：

用户 > LoginUser、AppUser、SystemUser、CMSUser、...

或者使用臭名昭著的方括号[用户]

【讨论】：

我敢打赌，如果你在袜子抽屉上贴上标签，你会称它为“袜子”。
明确地说。很难找到一种适用于所有人和所有人的标准，重要的是它适合你。这对我有用，在这里我已经解释了原因，但同样，这对我来说很方便。
克里斯的更大问题是，为什么在命名袜子抽屉时要遵循数据库命名约定？
这个答案需要更多的赞美。它讨论了我为什么喜欢单数名称的一系列实际原因。关于集合的适当语言的替代讨论只是哲学性的，并且掩盖了真正的意义。单数效果更好。
我家里有一个“袜子”抽屉，而不是“袜子”抽屉。如果它是一个数据库，我会称它为“Sock”表。

【解决方案2】：

我的看法是语义取决于你如何定义你的容器。例如，“一袋苹果”或简单的“苹果”或“苹果袋”或“苹果”。

示例： “学院”表可以包含 0 个或多个学院一个“colleges”表可以包含 0 个或多个 collegues

a "student" table can contain 0 or more students 
a table of "students" can contain 0 or more students.

我的结论是，两者都可以，但你必须定义你（或与之交互的人）在引用表格时将如何处理； “x 表”或“xs 表”

【讨论】：

【解决方案3】：

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

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

为什么要在单个对象名称的末尾添加一个“s”？通过将这个“s”放在对象名称的末尾，您想表示什么？

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

至少 3 个字符的后缀 - 这可以阻止此讨论。

表是一个数据库对象 - 与任何其他对象没有什么不同。

节省 3 个字符除了含义清晰之外什么也没有节省。

红色 ;-)

【讨论】：

加'Table'比加'_tbl'难多少？
为了更清楚，表定义实际上是一个潜在行的定义。
根据你自己的定义，你给了两个不同的东西同名......将被放置在表中的对象，以及保存这些对象的表。如果我说 Car，我指的是表还是表中的记录？如果我说汽车，很明显我的意思是拥有零个或多个汽车对象的东西。使用复数正确区分一个项目和持有它们的东西。如果你说 CarTable 是单数的话。但是如果没有后缀“table”，你必须给它一个代表它所拥有的名称。 “袜子抽屉”（单数）上面有标签（名称）“袜子”。

【解决方案4】：

我只为我的表名使用拼写相同的名词，无论是单数还是复数：

驼鹿鱼鹿飞机你裤子短裤眼镜剪刀物种后代

【讨论】：

【解决方案5】：

如果我们查看MS SQL Server's 系统表，Microsoft 为其分配的名称在plural。

Oracle 的系统表在singular 中命名。尽管其中一些是复数形式。 Oracle 建议用户定义的表名使用复数形式。他们推荐一件事并遵循另一件事并没有多大意义。这两个软件巨头的架构师使用不同的约定来命名他们的表，也没有多大意义......毕竟，这些人是什么......博士？

我确实记得在学术界，建议是单一的。

例如，当我们说：

select OrderHeader.ID FROM OrderHeader WHERE OrderHeader.Reference = 'ABC123'

也许 b/c 每个 ID 都是从特定的单行中选择的...？

【讨论】：

微软之所以如此，首先是出于商业原因（通常是不道德的原因），然后才是逻辑原因。我追随他们的唯一原因是他们是大猩猩，其他人都这样。当我有选择的时候，我会选择另一种方式。
两件事。一，您通常不会使用表名，而是会写 'select ID FROM OrderHeaders WHERE Reference = 'ABC123' 因为您是 'Selecting all IDs from OrderHeaders where something is true' 但是如果您必须使用表名，因为加入或其他什么，你会使用这样的别名...'select OrderHeader.ID FROM OrderHeaders as OrderHeader WHERE OrderHeader.Reference = 'ABC123'

【解决方案6】：

表的 SQL 定义实际上是表的一个潜在行的定义，而不是集合。因此，该定义中使用的名称必须指定行的类型，而不是集合的名称。喜欢复数的人，因为它在他们的英语语句中读起来很好，需要开始更有逻辑地思考，并查看实际使用表格所涉及的所有逻辑和编程代码。这些 cmets 中提到了使用单数表名的几个很好的理由。这些包括非常好的理由不使用复数表名。 “读得好”根本不应该是任何理由，尤其是因为有些人可能对这个想法有不同的理解。

【讨论】：

不，表的 SQL 定义是该表中所有行的定义，而不是您所说的一个潜在行。例如，使用你的定义，如果我说本周末的一个潜在约会对象是红发女郎，那并不意味着我不能和黑发女郎一起出去。然而，如果说所有本周末的潜在约会对象都是红发女郎会排除这种情况，而这正是餐桌的作用。它限制 all 行以匹配该描述，或者换句话说，它是对所有行的描述——“rows”这个词是复数，因此表格也应该是复数。
扩展这个想法，定义中的每一列也应该是复数。
我知道您是如何到达那里的，但我认为这是因为您将列视为一个容器，但事实并非如此。换句话说，列只是用于存储行属性的元数据。列数据本身不存在于行之外，因为行是它的存储位置。当您查询一列时，您正在查询该列数据的行。您不是自动查询该列。行是实体。该表是这些实体的集合。列只是该实体上的一个属性。
我在开玩笑。表可能包含行的集合，但表定义不是集合的定义，它是表行的定义，因此必须是单数的。如果您将表定义转换为处理它的程序的类定义，所有这些都会非常清楚。

【解决方案7】：

我曾经在 User 表中使用过“Dude”——同样的短字符数，与关键字没有冲突，仍然是对一般人的引用。如果我不担心可能会看到代码的闷头，我会保持这种状态。

【讨论】：

【解决方案8】：

我在之前的任何答案中都没有清楚地表达这一点。许多程序员在处理表时并没有考虑到正式的定义。我们经常用“记录”或“行”来直观地交流。但是，除了非规范化关系的一些例外情况，通常在设计表时使非键属性和键之间的关系构成一个集合论函数。

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

【讨论】：

【解决方案9】：

我个人更喜欢使用复数名称来表示一个集合，这对我的关系思维来说“听起来”更好。

此时此刻，我正在使用单数名称来为我的公司定义数据模型，因为大多数工作人员都觉得它更舒服。有时你只需要让每个人的生活更轻松，而不是强加你的个人喜好。（这就是我在这个线程中结束的方式，以确认命名表的“最佳实践”应该是什么）

在阅读了这个帖子中的所有争论之后，我得出了一个结论：

我喜欢我的蜂蜜煎饼，不管大家最喜欢什么口味。但如果我为其他人做饭，我会尝试为他们提供他们喜欢的东西。

【讨论】：

在关系模型世界中使用这样的约定是不明智的，尤其是当你描述对象之间的关系时，例如“每个 Team 可能只有一个 Main Coach 和多个 Secondary Coaches”，描述为： Team->MainCoach , Team->>SecondaryCoach

【解决方案10】：

在寻找良好的命名约定时，会出现以下混淆，我应该命名：

1) 符合。 表格的内容 例如：用户表。它总是会是复数的。所以，用户

2) 符合。 记录所拥有的 例如：用户表中的记录将是单个用户。所以，用户。

现在，主要是 users_roles 的问题。案例1：根据。第一个命名约定，users_roles 此名称的含义、用户及其角色。

案例2：根据。到第二个命名约定，user_role 这个名字的含义，用户和他的角色。

良好的命名约定是提供实体关系的附加概念，尤其是在存储多对多关系时。

在这里，根据场景，我们应该识别为信息集。

在用户表中，形成的所有集合都是唯一用户。在 Roles 表中，形成的所有集合都是唯一的角色。在用户和角色关系表中，可以用不同的角色形成用户集，这给出了存储1-多关系的想法。

I would prefer,
Users table => user
Roles table => role
users role relationship table => user_roles

【讨论】：

【解决方案11】：

两个站点的论文不同，我认为你只需要选择你的立场。就个人而言，我更喜欢 Plurar 用于表命名，当然也更喜欢单数用于列命名。

我喜欢你如何阅读这个：

SELECT CustomerName FROM Customers WHERE CustomerID = 100;

我们确实有 OOP，而且很棒，但大多数人继续使用关系数据库，而不是对象数据库。无需遵循关系数据库的 OOP 概念。

另一个例子，你有一个表 Teams，它保留了 TeamID、TeamColor 以及 PlayerID，并且对于一定数量的 PlayerID 将具有相同的 teamID 和 TeamColor...

玩家属于哪支球队？

SELECT * FROM Teams WHERE PlayerID = X

X Team 的所有玩家？

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

【讨论】：

听起来联盟数据库需要一些规范化，但我同意你的观点。