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

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

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

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

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

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

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

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

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

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

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

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

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

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

红色；-）

如果您使用Zend Framework（PHP）等特定框架，那么明智的做法是表类使用复数，行类使用单数。

因此，假设您创建了一个表对象$users=newUsers（），并将行类声明为User，那么您也可以调用newUser（）。

现在，如果对表名使用单数，则必须执行类似于newUserTable（）的操作，其中的行是newUserRow（）。对我来说，这看起来比为表设置对象Users（）和为行设置User（）对象更笨拙。

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

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

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

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

AppUserGroup关系告诉哪些实体是AppUserGroups

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

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

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

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

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

可能的替代方案：

重命名表SystemUser使用括号保留多个表名。

IMO使用括号从技术上来说是最安全的方法，尽管它有点麻烦。IMO是一个6个，另一个6打，您的解决方案实际上只是归结为个人/团队偏好。