关于这个主题的其他问题，我已经阅读了SO，而且我知道命名约定通常是主观的主题，但我觉得这不太通用（并且不太了解 ）PascalCase与under_scores相比。
给定一个简单的商业系统，User和Product个实体;给定用户可以购买商品，交易记录存储在User_Product表中。 （当然，Purchase更具语义性，但只需跟随我）
无论如何，如果我要介绍“投票”产品和“收藏”产品的能力，User_Product计划不再是明确的。
使用Name_Verb_Name的命名方案是不常见的（因此我会假设不太可接受的），如下所示：
User_Purchase_Product User_Vote_Product User_Favorite_Product 我没有机会在我的工作中使用任何“企业级”系统，所以在我的个人发展中，我充满了关于命名方案的问题，试图采用最普遍的方式。
我理解使用的一致性通常胜过所选惯例的语义，但又一次;尽力使我的惯例尽可能标准化。
（请注意，正如我所提到的，Purchase对于上述内容来说可能是语义上更好的选择，但我更好一点，当这样的语义可能不存在或足够简洁时 ）
答案 0 :(得分：3)
命名约定不是标准！
科学不是主观的！
有标准，标准有原因。 30多年前，所有这些问题都得到了回答和标准化。请阅读我的IDEF1X Introduction， IDFE1X 是关系数据库建模标准，没有其他。
首先，没有“相交”或“链接”表，每个表都有一个特定的目的，这是在建模练习中确定的，而不是链接表或交叉路径。当你采用这种正式方法时，表格及其含义自然会暴露出来。
其次，如果您需要关系数据库，则需要根据关系模型实现关系密钥或关系标识符。关系识别或识别。这意味着没有代理人。表不是孤立的二维生物，一旦确定了识别标识符，逻辑或第三维就变得清晰了。
通常这意味着复合键。
第三，如果您在建模过程中使用IDEF1X标准，您将拥有动词短语（详见链接）。它们非常清楚地识别表格之间的关系。再次，“交叉”和“链接”被消除，你有正确的名称和含义。
使用的一致性无关紧要，数据的一致性和意义的一致性是相关的。对数据建模，而不是使用。
因此，当您在问题中评估问题时，所需的命名是明确的;它是已经确定和建模的扩展。不需要三部分名称，两部分名称就足够了。
User和Product表格 UserProduct不是上述推理的完整名称
让我们说他们独立
UserPK加上ProductPK Each User Favours zero-to-many Products 我将其命名为UserFavoured或UserFavourite
User_Favourite_Product超载，第三部分是多余的
同样，Each User Elects zero-to-many Products（或Supports或Elevates）
UserPK加ProductPK（除非您喜欢重复）UserElected或UserElection 以上是关联表（你称之为'链接'）或添加了几个列。购买大不相同（不是'链接'）。必须为“购买”记录各种详细信息，User或Product中不存在这些详细信息。
Purchase UserPurchase多余且愚蠢UserPurchaseProduct是愚蠢的平方（我维持了你的问题的限制。实际上，没有购买表，会有SalesOrder形成购买的基础，商业活动，{{1} }，其中详细说明了SalesOrderItem。）
答案 1 :(得分：1)
正如Oded指出的那样，你应该选择一个约定并尽可能保持一致。
我一直发现的一件事是，标准是试图将常识制度化的经验法则。因此，仅仅询问您的标准是什么，您需要询问它为您购买的东西。在很多时候，任何特定标准的最大优势之一就是坚持它可以使您的系统一致性 - 这很有价值，因为它使系统更容易理解 （至少一旦习惯了系统中使用的约定）。
如果您的命名约定最终旨在使您的系统易于理解，那么选择易于理解的名称会不会更好？
这是我们进入纯粹意见领域的地方，但PURCHASE在我看来比USER_PURCHASE_PRODUCT更容易理解。我的经验法则是使用大多数人在命名表时会理解的简单语言 - 尤其是包含有关业务重要实体的数据的表。如果简单，一般公共语言不会这样做，那么使用一些特定于业务的术语（尽管随着业务的发展，这可能会有所变化）。
@Bracketworks，您询问的情况是没有明显的商家名称或名称不够精确的情况。我不确定这个“问题案例”不是自我强加的。我认为任何一张桌子都会有一个明智的名字。有时你必须认真思考它。如果您记得表的名称需要在表所在的数据库的上下文中有意义（并且不一定在此上下文之外），那么很多时候您将使您的生活更轻松。你应该在某个地方有一些文档 - 比如系统支持wiki - 它为你提供解释语义错综复杂所需的所有空间。表名只需要足够明智，以便在表生存和工作的系统的上下文中清楚。
对于noun_verb_noun，我自己不会选择强调机械一致性的命名约定，而不考虑它如何影响系统组件的可理解性。然而，与往常一样，关于标准的伟大之处在于有很多选择！
答案 2 :(得分：0)
没有“标准”，这完全主观。
与这些事情一样 - 在任何一个项目中选择一个并坚持下去。