我不喜欢复数表名，因为英语中的一些名词是不可数的（水、汤、现金），或者当你使其可数时，其含义会发生变化（鸡vs鸡；肉vs鸟）。我也不喜欢使用表名或列名的缩写，因为这样做会给已经陡峭的学习曲线增加额外的斜率。

具有讽刺意味的是，我可能会将User作为一个例外，并将其称为User，因为User（Transac SQL），因为如果不需要的话，我也不喜欢在表周围使用括号。

我还喜欢将所有ID列命名为ID，而不是ChickenId或ChickenId（复数个家伙对此做什么？）。

这一切都是因为我对数据库系统没有适当的尊重，我只是在重新应用OO命名约定中的一个技巧，比如Java的习惯和懒惰。我希望有更好的IDE支持复杂的SQL。

指导方针确实如此。这不是“板上钉钉”，这就是为什么你可以选择忽略它们。

我想说，使用多个表名在逻辑上更直观。表毕竟是实体的集合。除了提到的其他选项，我通常在表名上看到前缀。。。

tbl用户tbl此待定tbl其他

我并不是建议这样做，我也看到表名中使用了很多空格，我对此深恶痛绝。我甚至遇到过带有白痴字符的域名，比如？好像说这个字段回答了一个问题。

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

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

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

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

单数的我不相信任何涉及最合乎逻辑的论点——每个人都认为自己的偏好最合乎逻辑。无论你做什么，这都是一团糟，只要选择一个惯例并坚持下去。我们正试图将一种语法和语义高度不规则的语言（正常的口语和书面语言）映射到一种具有非常特定语义的高度规则（SQL）语法。

我的主要论点是，我不认为表格是一个集合，而是一个关系。

因此，AppUser关系告诉哪些实体是AppUsers。

AppUserGroup关系告诉哪些实体是AppUserGroups

AppUser_AppUserGroup关系告诉AppUsers和AppUserGroups是如何关联的。

AppUserGroup_AppUserGroup关系告诉AppUserGroups和AppUserGroup是如何关联的（即组中的组成员）。

换句话说，当我想到实体以及它们是如何关联的时候，我想到的是单数的关系，但当然，当我想起集合或集合中的实体时，集合或集合是复数的。

在我的代码和数据库模式中，我使用单数。在文本描述中，为了提高可读性，我最终使用了复数形式，然后使用字体等将表/关系名称与复数形式区分开来。

我喜欢认为它是混乱的，但有系统的——这样，我想表达的关系总是有一个系统生成的名称，这对我来说非常重要。

我曾经在User表中使用过“Dude”——同样短的字符数，与关键字没有冲突，仍然是对普通人的引用。如果我不担心那些可能看到代码的愚蠢的人，我会一直这样做。

我总是使用单一的表名，但正如前面所述，最重要的是保持一致，并对所有名称使用相同的形式。

我不喜欢多个表名，因为组合的名称可能会很奇怪。例如，如果您有一个名为Users的表，并且您想存储用户的财产，那么这将导致一个名称为UsersProperties的表。。。