MySQL 有命名约定吗？答案

【问题标题】：Is there a naming convention for MySQL?MySQL 有命名约定吗？
【发布时间】：2011-12-15 11:58:48
【问题描述】：

我是这样做的：

表名小写，使用下划线分隔单词，并且是单数（例如foo、foo_bar等
我通常（并非总是）有一个自动增量 PK。我使用以下约定：tablename_id（例如foo_id、foo_bar_id 等）。
当表包含作为外键的列时，我只需从它来自的任何表中复制该键的列名。例如，假设表 foo_bar 具有 FK foo_id（其中 foo_id 是 foo 的 PK）。
在定义 FK 以强制执行参照完整性时，我使用以下代码：tablename_fk_columnname（例如，进一步扩展示例 3，它将是 foo_bar_foo_id）。由于这是一个表名/列名组合，因此保证在数据库中是唯一的。
我按如下方式对列进行排序：PK、FK，然后按字母顺序排列其余列

有没有更好、更标准的方法来做到这一点？

【问题讨论】：

自动递增 PK 只使用“id”是错误的吗？为什么？列的名称仅在表的上下文中才有意义。所以我在每个表中都有一个“id”，并且可能有很多 id_ 用于 FK。
@Zbyszek 我认为最简单的反对理由只是为了一致性/简单性。而不是id_tableB => oh no 不同名称的列 id，id_tableB => id_tableB 的一致性看起来更整洁......正如 OP 所做的那样：foo_id => foo_id 而不是 foo_id => id
这是一个很好的方法。我使用的几乎相同，但对于表名，我使用复数表示“根”表，使用单数表示依赖项。例如：公司和 company_sector。
“表名 (...) 是单数的”，这在计算机工程数据库类中会立即失败。不是因为命名约定，而是因为“表”是一组东西。如果是单一的，则表明设计不佳。

标签： mysql naming-conventions mysql-workbench

【解决方案1】：

我首先要说的是：保持一致。

我认为您在问题中概述的约定几乎就在那里。不过有几个cmets：

我认为第 1 点和第 2 点很好。

第 3 点 - 遗憾的是，这并不总是可行的。考虑一下您将如何处理具有列foo_id 和another_foo_id 的单个表foo_bar，这两个列都引用foo 表foo_id 列。您可能要考虑如何处理这个问题。不过，这有点极端！

第 4 点 - 类似于第 3 点。您可能希望在外键名称的末尾引入一个数字，以适应多个引用列。

第 5 点 - 我会避免这种情况。当您想在以后从表中添加或删除列时，它几乎不会为您提供任何帮助。

其他几点是：

索引命名约定

您可能希望为索引引入一个命名约定 - 这对于您可能想要执行的任何数据库元数据工作都有很大帮助。例如，您可能只想调用索引 foo_bar_idx1 或 foo_idx1 - 完全取决于您，但值得考虑。

单数与复数列名

在列名和表名中解决复数与单数的棘手问题可能是一个好主意。这个主题经常在 DB 社区引起big debates。我会坚持表名和列的单数形式。那里。我已经说过了。

这里最重要的当然是一致性！

【讨论】：

有什么比第 5 点更好？为什么会让人头疼？
跟进，我发现这对以后会来这里的人很有帮助：launchbylunch.com/posts/2014/Feb/16/sql-naming-conventions/…
我很难找到一个好的“方案”来命名我的表格，这些表格包含由两个名称（DocumentChapter、DocumentVersion、DocumentType 等）组成的模型对象。例如，对于 DocumentType，我可以将其命名为 documenttype 或 document_type。我更喜欢后者，但大多数时候我有一个多对多的关系，我需要一个看起来像document_document_type 的表。有什么建议如何处理吗？
@rsb2097 回复：第 5 点 - 添加一列（到末尾）后，订单可能无效。您不应添加任何需要对列重新排序的约束，因为这是不必要的开销。

【解决方案2】：

一致性是任何命名标准的关键。只要它合乎逻辑且始终如一，您就成功了 99%。

标准本身是非常个人的偏好 - 所以如果你喜欢你的标准，那就按照它来运行。

要直接回答您的问题 - 不，MySQL 没有首选的命名约定/标准，因此您自己的命名约定/标准很好（而且您的似乎合乎逻辑）。

【讨论】：

【解决方案3】：

MySQL 对其或多或少严格的规则有一个简短的描述：

https://dev.mysql.com/doc/internals/en/coding-style.html

Simon Holywell 最常见的 MySQL 编码风格：

http://www.sqlstyle.guide/

另请参阅此问题： Are there any published coding style guidelines for SQL?

【讨论】：

这是一个很好的参考。 sqlstyle.guide 有一套非常全面的指南，几乎涵盖了任何情况。

【解决方案4】：

谢天谢地，PHP 开发人员不像我认识的一些开发社区那样“偏执”。

你的约定听起来不错。

只要它们 a) 简单，b) 一致 - 我看不出有任何问题 :)

PS：就个人而言，我认为 5) 是矫枉过正...

【讨论】：

远非偏执狂，驼峰式大小写实际上受到许多 DB 社区的反对，因为某些 RDBMS 对大小写不敏感，以至于它们会剥离大小写（或将所有内容更改为大写）所以事情很快就会变得非常丑陋。
@mwan：你能指定哪个 RDBMS 吗？我自己也是一名骆驼骑师。大写在我的模式中仅用于一个目的，表示连接表和（在字段的情况下）表示单词边界，因此 _ 可能专门表示 othertable_id （即表名 = othertable 和该表中的字段 = id ）。此外，如果其他 RDBMS 不区分大小写，那有什么关系呢？我永远不会使用同一张表的大写和小写版本！哦，我不喜欢不区分大小写的 RDBMS - 我宁愿编写一致的代码
我喜欢 MySQL 用户不喜欢 CamelCase 的讽刺和我们使用的产品名称：MySQL，用 CamelCase 编写
@DBX12 迂腐，这是 PascalCase，不是 camelCase，但你的观点仍然成立。
@MarredCheese 从来没想过，但你是对的。 camelCase 一开始应该没有驼峰。

【解决方案5】：

简单回答：不

好吧，至少是 Oracle 或社区鼓励的命名约定，但不，基本上你必须注意标识符的规则和限制，例如 MySQL 文档中指出的：https://dev.mysql.com/doc/refman/8.0/en/identifiers.html

关于您遵循的命名约定，我认为还可以，只是数字 5 有点不必要，我认为大多数用于管理数据库的可视化工具都提供了对列名进行排序的选项（我使用 DBeaver，它有)，所以如果你的目的是让你的桌子有一个很好的视觉呈现，你可以使用我提到的这个选项。

根据个人经验，我会推荐这个：

使用小写。当您将数据库从一台服务器迁移到另一台服务器时，这几乎可以确保互操作性。有时，lower_case_table_names 配置不正确，您的服务器仅通过简单地无法识别您的 camelCase 或 PascalCase 标准（区分大小写问题）就开始抛出错误。
简称。简单明了。最简单快捷的是识别您的表或列，效果越好。相信我，当您在短时间内进行大量不同的查询时，最好让所有内容都易于编写（和阅读）。
避免使用前缀。除非您对不同应用程序的表使用相同的数据库，否则不要使用前缀。这只会增加您的查询的详细程度。在某些情况下，这可能很有用，例如，当您想要识别主键和外键时，通常将表名用作 id 列的前缀。
使用下划线分隔单词。如果您仍想使用多个单词来命名表格、列等，请在 separating_the_words 中使用下划线，这有助于提高可读性（您的眼睛和紧张的大脑会感谢您） .
保持一致。一旦你有了自己的标准，就遵循它。不要成为制定规则的人，并且是第一个破坏规则的人，那是可耻的。

那么“复数 vs 单数”的命名呢？好吧，这主要是个人喜好的情况。在我的例子中，我尝试对表使用复数名称，因为我认为表是元素的集合或包含元素的包，所以复数名称对我来说是有意义的；和列的单数名称，因为我将列视为单独描述这些表元素的属性。

【讨论】：

【解决方案6】：

一致性是每个人都强烈建议的，其余的取决于你，只要它有效。

对于初学者来说，它很容易被带走，我们当时想取什么名字就取什么名字。这在当时是有道理的，但后来就让人头疼了。

foo foobar 或 foo_bar 很棒。我们尽可能直接命名我们的表格，并且仅在它们是两个不同的单词时使用下划线。 studentregistration 到 student_registration

就像@Zbyszek 所说，拥有一个简单的id 对于自动增量来说绰绰有余。越简单越好。为什么需要foo_id？我们很早就遇到了同样的问题，我们用表前缀命名了所有列。比如foo_id、foo_name、foo_age。我们现在删除了表名，只保留了尽可能短的 col。

由于我们只使用 PK 的 id，我们将使用 foo_bar_fk（表名是唯一的，后跟唯一的 PK，然后是 _fk）作为外键。我们不会在 col 名称中添加 id，因为据说名称 'id' 始终是给定表的 PK。所以我们只有表名和最后的_fk。

对于约束，我们删除所有下划线并加入 camelCase (tablename + Colname + Fk) foobarUsernameFk (for username_fk col)。这只是我们遵循的一种方式。我们为每个名称结构保留一份文档。

在保持 col 名称简短时，我们还应该注意 RESTRICTED 名称。

+------------------------------------+
|               foobar               |
+------------------------------------+
| id (PK for the current table)      |
| username_fk (PK of username table) |
| location (other column)            |
| tel (other column)                 |
+------------------------------------+

【讨论】：

【解决方案7】：

正如@fabrizio-valencia 所说，使用小写字母。在 Windows 中，如果您导出 mysql 数据库（phpmyadmin），表名将转换为小写，这会导致各种问题。见Are table names in MySQL case sensitive?

【讨论】：