我也赞成iso/iec11179风格的命名约定，指出它们是指导原则而不是规定性的。
请参见wikipedia上的数据元素名称：
“表是实体的集合，遵循集合命名准则。理想情况下，使用集体名称：例如人员。复数形式也正确：雇员。不正确的名称包括：employee、tblemployee和employeetable。“
和往常一样，规则也有例外，例如总是只有一行的表最好使用单数名称，例如配置表。而一致性是最重要的：检查你的商店是否有一个惯例，如果有，遵循它；如果你不喜欢它，那么做一个商业案例，让它改变，而不是成为一个孤独的护林员。

在这里迟回答，但简而言之：
我喜欢复数形式
对
表格：通常没有前缀是最好的。列：否。
表和列：pascalcase。
精化：
（1） 你必须做的。有很少的事情，你必须做的某种方式，每一次，但有几个。
使用“[singularoftablename]id”格式命名主键。也就是说，无论您的表名是customer还是customers，主键都应该是customerid。
此外，外键必须在不同的表中统一命名。殴打不这样做的人应该是合法的。我认为，虽然定义的外键约束通常很重要，但一致的外键命名始终很重要
数据库必须有内部约定。尽管在后面的章节中您会看到我非常灵活，但在数据库中命名必须非常一致。无论您的客户表是称为customers还是customer，都不如在同一个数据库中以相同的方式来处理它重要。你可以掷硬币来决定如何使用下划线，但是你必须用同样的方法来使用它们。如果你不这样做，你就是一个应该自卑的坏人。
（2） 你应该怎么做。
表示不同表上相同类型数据的字段应命名相同。不要一张table上有拉链，另一张table上有拉链。
要分隔表名或列名中的单词，请使用pascalcasing。使用camelcasing在本质上不会有问题，但这不是惯例，看起来很有趣。我马上要讲下划线(你不能像以前那样使用所有的大写字母。20年前，obnoxioustable.u列在db2中还可以，但现在不行。）
不要人为地缩短或缩写单词。一个名字长而清晰，总比短而混乱好。超短名字是从黑暗、野蛮时代遗留下来的。客户地址。那到底是什么？保管收件人参考？客户额外退款？自定义地址？
（3）你应该考虑什么。
我真的认为你的table应该有复数的名字；有些人认为很奇怪。阅读别处的论点。但是列名应该是单数。即使使用复数表名，表示其他表组合的表也可能是单数的。例如，如果您有一个promotions和一个items表，那么表示作为promotion一部分的项的表可以是promotions\u items，但我认为它也可以合法地是promotion\u items（反映一对多关系）。
为了特定的目的，一致地使用下划线。只是一般的表名应该用pascalcasing足够清楚；你不需要下划线来分隔单词。保存下划线（a）表示关联表，或（b）表示前缀，我将在下一个项目符号中说明。
前缀既不好也不坏。这通常不是最好的。在您的前一两个db中，我不建议对表的一般主题分组使用前缀。表最终不容易适合您的类别，这实际上会使查找表变得更加困难。有经验的话，你可以计划并应用一个有利多于弊的前缀方案。我曾经在一个数据库工作过，那里的数据表以tbl开头，配置表以ctbl开头，视图以vew开头，proc的sp和udf的fn等等；这是一丝不苟，始终如一的应用，所以它的结果是好的。你唯一需要前缀的时候是当你有真正独立的解决方案，由于某种原因，它们驻留在同一个数据库中；在它们前面加上前缀对分组表非常有帮助。在特殊情况下，前缀也是可以的，比如您希望突出显示的临时表。
很少（如果有的话）需要在列前面加前缀。

我在一个有三位DBA的数据库支持团队中工作，我们考虑的选项是：
任何命名标准都比没有标准好。
没有“一个真实”的标准，我们都有自己的喜好
如果已经有了标准，就使用它。不要创建另一个标准，也不要将现有标准弄脏。
我们对表格使用单数名称。表格往往以系统名称（或其缩写）作为前缀。如果系统比较复杂，这很有用，因为您可以更改前缀以逻辑方式将表分组在一起（即reg\U customer、reg\U BOCKING和regadmin\U limits）。
对于字段，我们希望字段名包括表的前缀/acryonm（即cust\u address1），并且我们还希望使用一组标准的后缀（pk的\u id、“code”的\u cd、“name”的\u nm、“number”的\u nb、“date”的\u dt）。
外键字段的名称应与主键字段的名称相同。
即。

SELECT cust_nm, cust_add1, booking_dt
FROM reg_customer
INNER JOIN reg_booking
ON reg_customer.cust_id = reg_booking.cust_id

在开发一个新项目时，我建议您写出所有首选的实体名称、前缀和缩写词，并将此文档交给您的开发人员。然后，当他们决定创建一个新表时，他们可以引用文档，而不是“猜测”应该调用什么表和字段。

我经常听到这样一种说法：一张table是否多元化完全是个人品味的问题，没有最佳实践。我不相信这是真的，尤其是作为程序员而不是dba。据我所知，除了“它对我来说很有意义，因为它是一个对象的集合”之外，没有合法的理由将表名复数化，而使用单数表名在代码中有合法的好处。例如：
它避免了由复数歧义引起的bug和错误。程序员并不是以他们的拼写专业知识而闻名的，将一些单词复数化是令人困惑的。例如，复数的单词是以“es”结尾还是仅仅以“s”结尾？是人还是人？当您与大型团队一起处理项目时，这可能会成为一个问题。例如，一个示例，其中一个团队成员使用错误的方法对他创建的表进行复数化。当我与这个表交互时，它在我无法访问或需要很长时间才能修复的代码中被全部使用。结果是每次我用这个表时都要记住把它拼错。类似的事情发生在我身上。您越容易让团队中的每个成员一致、轻松地使用准确、正确的表名，而不出现错误，或者不必一直查找表名，就越好。单一版本在团队环境中更容易处理。
如果使用单数版本的表名并在主键前面加上表名，那么现在就可以通过代码轻松地从主键确定表名，反之亦然。您可以得到一个包含表名的变量，将“id”连接到末尾，现在您就可以通过代码获得表的主键，而无需执行额外的查询。或者您可以从主键的末尾切断“id”，通过代码确定表名。如果使用“id”而主键没有表名，则无法通过代码从主键确定表名。此外，大多数将表名复数化并在pk列前面加上表名前缀的人在pk中使用表名的单数版本（例如statuses和status\u id），这使得它在pk中非常重要

好吧，既然我们在权衡意见：
我认为表名应该是复数的。表是实体的集合（表）。每行表示一个实体，表表示集合。所以我会称之为人-实体-人（或人，随便你怎么想）。
对于那些希望在查询中看到单数“实体名称”的人，我将使用表别名：

SELECT person.Name
FROM People person

有点像linq的“从人中选择人的名字”。
至于2，3和4，我同意@lars。

我建议查看microsoft的sql server示例数据库：https://github.com/microsoft/sql-server-samples/releases/tag/adventureworks
adventureworks示例使用非常清晰和一致的命名约定，该约定使用模式名称来组织数据库对象。
表的单数名称
列的单数名称
表前缀的架构名称（例如：schemename.tablename）
帕斯卡套管（又称上 Camel 套管）

不可以。表应该以它所代表的实体命名。“人，而不是人”是指记录中代表的人。
同样的道理。firstname列实际上不应该被称为firstnames。这完全取决于您想用列表示什么。
不。
对。为清楚起见，请将其装箱。如果您需要像“firstname”这样的列，那么casing将使其更易于阅读。
好 啊。那是我的0.02美元