关系表命名约定

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

想要改进这个问题？更新问题，以便可以通过编辑这篇文章用事实和引文来回答它。

4 年前已关闭。

社区在3年前审查了是否重新开放此问题，并将其关闭：

原始关闭原因未解决

Answer 1

表格•名称

最近学到的单数是正确的

是的。表名中的复数显然表明某人没有阅读过任何标准材料并且不了解数据库理论。

标准的一些美妙之处是：

• 它们相互集成、
• 协同工作
• 、由比我们更伟大的人编写，因此我们不必
  辩论他们。

标准表名是指表中的每一行，用于所有用语，而不是表的全部内容（我们知道Customer表包含所有内容）客户）。

关系，动词短语

在已建模的真正关系数据库中（与 1970 年之前的记录归档系统相反 [以记录 ID 为特征，该系统在 SQL 数据库容器中实现方便）：

• 表是数据库的主题，因此它们是名词，同样，单数
• 表之间的关系是操作发生在名词之间，因此它们是动词（即它们不是任意编号或命名的）
• 谓语
• ，是所有可以阅读的 直接来自数据模型（请参阅最后的示例）
• （独立表（层次结构中最顶层的父级）的谓词是它是独立的），
• 因此动词短语是经过仔细选择的，因此它是最有意义的，并且避免使用通用术语（随着经验的增加，这会变得更容易）。动词短语在建模过程中很重要，因为它有助于解决模型，即。澄清关系、识别错误并更正表名。

[**Diagram_A**][Diagram_A]

当然，这种关系在 SQL 中作为子表中的 CONSTRAINT FOREIGN KEY 来实现（稍后会详细介绍）。这是动词短语（在模型中）、它代表的谓词（从模型中读取）以及 FK 约束名称 >：

    Initiates
    Each Customer Initiates 0-to-n SalesOrders
    Customer_Initiates_SalesOrder_fk

表格•语言

但是，在描述表格时，尤其是在谓词或其他文档等技术语言中，请使用单数和复数，因为它们在英语中自然使用。请记住，表是根据单行（关系）命名的，并且语言引用每个派生行（派生关系）：

    Each Customer initiates zero-to-many SalesOrders

不是

    Customers have zero-to-many SalesOrders 

那么，如果我有一个表“user”，然后我得到了只有该用户才能拥有的产品，该表应该命名为“user-product”还是仅命名为“product”？这是一对多的关系。

（这不是命名约定问题；这是数据库设计问题。）user::product 是否为 1 并不重要： ：n。重要的是product是否是一个单独的实体以及是否是一个独立表，即。它可以独立存在。因此产品，而不是user_product。

如果product仅存在于user的上下文中，即。它是一个从属表，因此是user_product。

[**Diagram_B**][Diagram_B]

进一步，如果我（出于某种原因）对每个产品有多个产品描述，它是“用户产品描述”还是“产品描述”还是只是“描述”？当然，如果设置了正确的外键..仅将其命名为描述就会有问题，因为我还可以有用户描述或帐户描述或其他任何内容。

是的。根据上述内容，user_product_description x 或 product_description 都是正确的。它不是为了将其与其他xxxx_descriptions区分开来，而是为了让名称感觉到它所属的位置，前缀是父表。

如果我想要一个只有两列的纯关系表（多对多），这会是什么样子？ “user-stuff”或者类似“rel-user-stuff”的东西？如果是第一个，它与“用户产品”等有何区别？

1. 希望关系数据库中的所有表都是纯关系的、规范化的表。无需在名称中标识它（否则所有表都将是 rel_something）。

2. 如果它仅包含两个父级的 PK（这会将逻辑级别上不作为实体存在的逻辑 n::n 关系解析为物理表），即关联表。是的，通常该名称是两个父表名称的组合。

   • 请注意，在这种情况下，动词短语适用于并且被解读为从父表到父表，忽略子表，因为它的唯一目的是将两个父表联系起来。

     
     [**图_C**][图_C]

   • 如果它不是关联表（即除了两个 PK 之外，它还包含数据），则对其进行适当命名，并且动词短语适用于它，而不是关系结束时的父母。

     
     [**图_D**][图_D]

3. 如果您最终得到两个 user_product 表，那么这是一个非常响亮的信号，表明您尚未对数据进行标准化。因此，请返回几步并执行此操作，并准确且一致地命名表。然后名称将自行解析。

命名约定

如果有你们推荐的某种命名约定标准，请随时链接。

您所做的事情非常重要，它将影响各个级别的易用性和理解。因此，在一开始就获得尽可能多的理解是有好处的。在您开始使用 SQL 进行编码之前，大部分内容的相关性都不会很清楚。

1. 案例是第一个要解决的项目。全部大写是不可接受的。混合大小写是正常的，特别是当用户可以直接访问表时。参考我的数据模型。请注意，当搜索者使用某种只有小写字母的 NonSQL 时，我会给出这一点，在这种情况下，我会包含下划线（根据您的示例）。

2. 保持数据焦点，而不是应用程序或使用焦点。自 1984 年以来，我们一直采用开放架构，数据库应该独立于使用它们的应用程序。

这样，随着它们的成长，并且不止一个应用程序使用它们，命名将保持有意义，并且不需要更正。 （完全嵌入到单个应用程序中的数据库不是数据库。）仅将数据元素命名为数据。

3. 要非常体贴，并且非常准确地命名表和列。如果是 DATETIME 数据类型，请不要使用 UpdatedDate，而应使用 UpdatedDtm。如果_description包含剂量，请勿使用。

4. 整个数据库保持一致非常重要。请勿在一处使用 NumProduct 来指示产品数量，而在另一处使用 ItemNo 或 ItemNum 来指示商品数量。一致地使用 NumSomething 表示数字，使用 SomethingNo 或 SomethingId 表示标识符。

5. 请勿在列名前添加表名或短代码，例如 user_first_name。 SQL 已经提供表名作为限定符：

    table_name.column_name -- 注意点
   

6. 例外：

   • 第一个例外是 PK，它们需要特殊处理，因为您始终在联接中对它们进行编码，并且您希望键从数据列中脱颖而出。始终使用 user_id，切勿使用 id。

     • 请注意，这不是用作前缀的表名称，而是键组件的正确描述性名称：user_id 是标识用户的列，而不是 user 表的 id。
       • （当然，除了在记录归档系统中，文件由代理访问并且没有关系键，它们是同一个东西）。
     • 无论何时将 PK 作为 FK 进行（迁移），都始终对键列使用完全相同的名称。
     • 因此，user_product 表将有一个 user_id 作为其 PK （user_id，product_no） 的组成部分。
     • 当您开始编码时，这一点的相关性就会变得清晰。首先，许多表上都有一个 id，很容易在 SQL 编码中混淆。其次，除了最初的编码员之外的任何人都不知道他想做什么。如果按上述方式处理关键列，这两种情况都很容易预防。

   • 第二个例外是有多个 FK 引用同一父表表（在子表中携带）。根据关系模型，使用角色名称来区分含义或用法，例如。两个 PartCodes 的 AssemblyCode 和 ComponentCode。在这种情况下，请不要对其中之一使用未区分的 PartCode。准确一点。

     Diagram_E

7. 前缀
   如果您有超过 100 个表，请在表名称前添加主题区域前缀：

   REF_ 用于参考表
   OE_ 用于订单输入集群等

   仅在物理层面，而不是逻辑层面（它会使模型变得混乱）。

8. 后缀
   切勿在表格上使用后缀，并始终在其他所有内容上使用后缀。这意味着在数据库的逻辑、正常使用中，没有下划线；但在管理方面，下划线用作分隔符：

   _V 视图（当然，主TableName在前面）
   _fk 外键（约束名称，而不是列名称）
   _cac 缓存
   _seg 段
   _tr 事务（存储过程或函数）
   _fn 函数（非事务性）等

格式是表或FK名称、下划线、动作名称、下划线、最后是后缀。

这非常重要，因为当服务器向您提供错误消息：

____blah blah blah error on object_name

时，您确切地知道哪个对象被侵犯，以及它试图执行的操作：

____blah blah Customer_Add_tr 上出现错误

8. 外键（约束，而不是列）。 FK 的最佳命名是使用动词短语（减去“each”和基数）。

   Customer_Initiates_SalesOrder_fk
Part_Comprises_Component_fk
Part_IsConsumedIn_Assembly_fk

使用 Parent_Child_fk 序列，而不是 Child_Parent_fk 是因为 (a) 当您查找它们时，它会以正确的排序顺序显示，并且 ( b) 我们总是知道所涉及的孩子，我们猜测的是哪个父母。然后错误消息令人愉快：

____Vendor_Offers_PartVendor_fk 上的外键违规。

这对于对数据进行建模的人来说非常有效，其中动词短语已被识别。对于其余的，记录归档系统等，使用Parent_Child_fk。

9. 索引很特殊，因此它们有自己的命名约定，由按顺序组成，每个字符位置从 1 到 3：

U 唯一，或 _ 表示非唯一
C 集群，或 _ 表示非集群
_ 分隔符

其余部分：
- 如果键是一列或极少数列：
____ColumnNames

- If the key is more than a few columns:  

____PK 主键（根据模型）
____AK[*n*] 备用键（IDEF1X 术语）

请注意，索引名称中不需要表名称，因为它始终显示为 table_name .index_name.

因此，当 Customer.UC_CustomerId 或 Product.U__AK 出现在错误消息中时，它会告诉您一些有意义的信息。当您查看表格上的索引时，您可以轻松地区分它们。

99. 找到合格且专业的人并跟随他们。看看他们的设计，并仔细研究他们使用的命名约定。向他们询问您不明白的任何具体问题。相反，对于那些不尊重命名约定或标准的人，请拼命远离。以下是一些可以帮助您入门的内容：

• 它们包含上述所有内容的真实示例。在此线程中提出重新命名问题的问题。
• 当然，除了命名约定之外，这些模型还实现了一些其他标准；您可以暂时忽略这些问题，也可以随意提出具体的新问题。
• 它们每页都有好几页，因此您必须单击链接。
• 请注意，PDF 文件具有完整的导航，因此单击蓝色玻璃按钮或标识扩展的对象：
• 不熟悉关系建模标准的读者可能会找到 IDEF1X 表示法很有帮助。

订单输入&具有符合标准的地址的库存

简单的办公室间公告 PHP/MySQL 系统

具有完整时间能力的传感器监控

问题的答案

^{不可能评论区合理回答。}

拉里·勒斯蒂格：
...即使是最微不足道的例子也表明...
如果客户有零对多产品，产品有一对多组件，组件有一对多供应商，供应商销售零对多组件，销售代表有一对多客户保存客户、产品、组件和供应商的表的“自然”名称是什么？

您的评论中有两个主要问题：

1. 您声明您的示例是“最微不足道的”，但是，它只不过是。面对这样的矛盾，我不确定你是否认真，是否有技术能力。

2. 这个“微不足道”的推测有几个严重的标准化（数据库设计）错误。

• 在你纠正这些错误之前，它们是不自然、不正常的，而且没有任何意义。您不妨将它们命名为异常_1、异常_2 等。

• 您有不提供任何东西的“供应商”；循环引用（非法且不必要）；客户购买产品时没有任何商业票据（例如发票或销售订单）作为购买依据（或者客户“拥有”产品吗？）；未解决的多对多关系；等等

• 一旦标准化，并且确定了所需的表，它们的名称将变得显而易见。当然。

无论如何，我会尽力解答您的疑问。这意味着我必须添加一些意义，不知道你的意思，所以请耐心等待。严重错误太多，无法一一列举，而且考虑到备用规范，我不确信我已经纠正了所有这些错误。

• 我假设如果产品是由组件组成的，那么该产品就是一个组件，并且组件用于多个组件中。

• 此外，由于“供应商销售零到多个组件”，因此他们不销售产品或组件，因此他们只销售组件。

投机与标准化模型

如果您不知道，方角（独立）和圆角（从属）之间的差异很大，请参阅 IDEF1X 符号链接。同样，实线（识别）与虚线（非识别）。

...保存客户、产品、组件和供应商的表的“自然”名称是什么？

• 客户
• 产品
• 组件
  （或者，AssemblyComponent，对于那些意识到一个事实可以识别另一个事实的人）
• Supplier

现在我已经解决了这些表，但我不明白您的问题。也许您可以发布具体问题。

谓词

投票咖啡：
您如何处理 Ronnis 在他的示例中发布的场景，其中两个表（user_likes_product、user_bought_product）之间存在多个关系？我可能会误解，但这似乎会导致使用您详细说明的约定产生重复的表名称。

假设没有规范化错误，User likes Product 是一个谓词，而不是一个表。不要混淆他们。请参阅我的答案，其中涉及主语、动词和谓语，以及我对上面拉里的回应。

• 每个表都包含一组事实（每行都是一个事实）。谓词（或命题）不是事实，它们可能是真的，也可能不是。

• 关系模型基于一阶谓词演算（通常称为一阶逻辑）。谓词是简单、精确的英语中的单从句句子，其计算结果为 true 或 false。

• 此外，每个表代表或实现许多谓词，而不是一个。

• 查询是对谓词（或链接在一起的多个谓词）的测试，结果为 true（事实存在）或 false（事实不存在）。

• 因此，应该按照我的答案（命名约定）中的详细说明，为行、事实和谓词命名表（无论如何，它是数据库文档的一部分），但作为单独的谓词列表。

• 这并不是说它们不重要。它们非常重要，但我不会在这里写下来。

• 那就快点吧。由于关系模型是建立在FOPC之上的，所以整个数据库可以说是一组FOPC声明，一组Predicates。但是（a）有多种类型的谓词，（b）一张表并不代表一个谓词（它是许多谓词的物理实现，并且具有不同的类型谓词）。

• 因此，将表命名为它“代表”的“the”谓词是一个荒谬的概念。

• “理论家”只知道几个谓词，他们不明白，由于 rm 是在FOL上建立的，因此整个数据库是一组谓词，并且具有不同的类型。

• 当然，他们从他们所知道的少数人中选择荒谬的人： ascome_person ; person_is_called 。如果不是那么难过，那会很有趣。

• 还请注意，标准表名称名称（命名行）非常适合所有词汇（包括附加到表上的所有谓词）。相反，“表代表谓词”名称不能，这对“理论家”来说是很好的，他们对谓词很少了解，但没有其他理解。

• 与数据模型相关的谓词在的模型中表达，它们是两个顺序。

  。
  

1. 一般谓词
   第一组是图表，而不是文本：符号本身。这些包括各种存在；面向约束；和描述符（属性）谓词。

• 当然，这意味着只能“读取”标准数据模型的人才能读取这些谓词。这就是为什么“理论家”严重受到文本思维方式严重瘫痪的“理论家”无法读取数据模型，为什么他们坚持使用1984年以前的只有文字思维方式。

2. 二元谓词
   第二组是事实之间形成关系的。这是关系线。动词短语（上面详细介绍）标识已实现的谓词命题（可以通过查询进行测试）。一个人不能比这更明确。

• 因此，对于一个流利的标准数据模型的人来说，所有相关的谓词在模型中都记录在模型中。他们不需要单独的谓词列表（但是无法从数据模型中“读取”所有内容的用户做！）

  。
  

• 这是 ，我列出了谓词。我之所以选择该示例，是因为它显示了存在等，谓词以及关系，唯一未列出的谓词是描述符。在这里，由于寻求者的学习水平，我将他视为用户。

因此，在两个父表之间有多个子表的事件不是问题，只需将它们命名为其内容，并将其标准化。

我为关联表的关系名称提供的动词短语提供的规则在这里发挥作用。这是 讨论，涵盖了所有提到的观点。

对于很好的简短说明，请正确使用谓词以及如何使用它们（这与此处回应评论的情况完全不同），请访问 此答案 ，然后向下滚动到谓词部分。

---

Charles Burns：
按顺序，我的意思是纯粹用于存储一个数字的oracle式对象，其下一个根据某些规则（例如“添加1”）。由于Oracle缺少自动ID表，因此我的典型用途是为表PK生成独特的ID。插入foo（id，somedata）值（foo_senextval，“ data” ...）

ok，这就是我们所说的键或nextKey表。这样命名。如果您患有主题，请使用com_nextkey表示在整个数据库中很常见。

顺便说一句，这是一种生成钥匙的非常差的方法。根本不可扩展，但是随着Oracle的性能，它可能“很好”。此外，这表明您的数据库充满了替代物，在这些领域不相关。这意味着表现极差和缺乏正直。

Answer 2

单数与复数：选择一个并坚持使用。

列不应带有前缀/后缀/中固定或以任何方式通过引用它是列这一事实来固定。桌子也是如此。不要将表命名为 EMPLOYEE_T 或 TBL_EMPLOYEES，因为当它被视图替换时，事情会变得非常混乱。

不要在名称中嵌入类型信息，例如 varchar 的“vc_firstname”或“flavour_enum”。也不要在列名称中嵌入约束，例如“department_fk”或“employee_pk”。

实际上，我能想到的关于 *fixes 的唯一好处是，您可以使用保留字，例如 where_t、tbl_order、user_vw。当然，在这些示例中，使用复数可以解决问题:)

不要将所有键命名为“ID”。引用同一事物的键在所有表中应具有相同的名称。用户 id 列在用户表和引用该用户的所有表中可以称为 USER_ID。唯一一次重命名是当不同的用户扮演不同的角色时，例如Message(sender_user_id,receiver_user_id)。这在处理较大的查询时确实很有帮助。

关于CaSe：

thisiswhatithinkofalllowercapscolumnnames.

ALLUPPERCAPSISNOTBETTERBECAUSEITFEELSLIKESOMEONEISSCREAMINGATME.

CamelCaseIsMarginallyBetterButItStillTakesTimeToParse.    

i_recommend_sticking_with_lower_case_and_underscore

一般来说，最好命名“映射表”以匹配它描述的关系，而不是引用表的名称。用户可以与产品有任意数量的关系：user_likes_product、user_bought_product、user_wants_to_buy_product。

Answer 3

单数和复数之间没有“正确”之分——这主要是一个品味问题。

这部分取决于您的关注点。如果您将表视为一个单元，那么它包含“复数”（因为它包含许多行 - 因此复数名称是合适的）。如果您将表名视为标识表中的行，那么您会更喜欢“单数”。这意味着您的 SQL 将被视为处理表中的一行。没关系，尽管这通常过于简单化了。 SQL 适用于集合（或多或少）。然而，我们可以用单数来回答这个问题。

1. 由于您可能需要一个表“用户”，另一个“产品”，第三个表将用户连接到产品，因此您需要一个表“user_product”。

2. 由于说明适用于产品，因此您可以使用“product_description”。除非每个用户为自己的每个产品命名...

3. “user_product”表是（或可能是）具有产品 ID 和用户 ID 的表的示例，仅此而已。您可以使用相同的通用方式命名两个属性表：“user_stuff”。像“rel_”这样的装饰性前缀并没有真正的帮助。例如，您会看到有些人在每个表名称前面使用“t_”。这没什么帮助。

Answer 4

只要一致使用，复数就不错——但我更喜欢单数。

除非您想概述多对多关系，否则我会省略下划线；并使用初始大写字母，因为它有助于区分 ORM 中的事物。

但是有很多命名约定，因此如果您想使用下划线，只要保持一致就可以。

所以：

User

UserProduct (it is a users products after all)

如果只有一个用户可以拥有任何产品，那么

UserProductDescription

但是如果该产品由用户共享：

ProductDescription

如果您为多对多关系保存下划线，您可以执行以下操作：

UserProduct_Stuff

在 UserProduct 和 Stuff 之间形成 M-to-M - 从问题中不确定所需的多对多的确切性质。

Answer 5

使用单数形式没有比使用复数形式更正确的了，您从哪里听说过？我宁愿说复数形式对于命名数据​​库表来说更常见......并且在我看来也更逻辑。该表通常包含不止一行；）在概念模型中，尽管实体的名称通常是单数。

关于您的问题，如果“产品”和“产品描述”是模型中具有身份（即实体）的概念，我将简单地将表称为“产品”和“产品描述”。对于用于实现多对多关系的表，我最常使用命名约定“SideA2SideB”，例如“Student2Course”。