我坚信，在实体关系图中，实体应该用一个单数名称来反映，类似于类名是单数。实例化后，名称将反映其实例。因此，对于数据库，当实体被制成表（实体或记录的集合）时，它是复数。实体，用户被制成表用户。我同意其他人的建议，也许User这个名字可以改为Employee，或者更适合您的场景。

这在SQL语句中更有意义，因为您正在从一组记录中进行选择，如果表名是单数，则读起来不好。

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

可能的替代方案：

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

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

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

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

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

IMHO，表名应该是复数，如Customer。

如果类名称映射到Customers表中的一行，则类名称应与Customer类似。

就“标准”而言，其他人给出了相当好的答案，但我只是想补充一下。。。是否可能“用户”（或“用户”）实际上不是表中数据的完整描述？并不是说你应该对表名和特定性太着迷，但也许像“Widget_Users”（其中“Widget”是应用程序或网站的名称）这样的东西会更合适。