Database 外键命名方案

我刚刚开始第一次使用外键，我想知道是否有一个标准的命名方案可以用于它们

鉴于这些表格：

task (id, userid, title)
note (id, taskid, userid, note);
user (id, name)

如果任务有注释，则任务由用户所有，用户拥有作者注释

在这种情况下，三个外键将如何命名？或者，这有什么关系吗

---

更新：这个问题是关于外键名，而不是字段名

FK_TABLENAME_COLUMNNAME怎么样

---

KeepItSimpleStupid只要有可能。

我通常只留下我的PK命名id，然后在其他表中命名FKs时连接我的表名和键列名。我从不使用驼峰式大小写，因为有些数据库放弃区分大小写，只返回所有大写或小写名称。在任何情况下，以下是我的表格版本：

task (id, userid, title);
note (id, taskid, userid, note);
user (id, name);

---

请注意，我也用单数命名我的表，因为一行表示我要持久化的对象之一。这些习俗中有许多是个人喜好。我建议，选择并始终使用约定比采用其他人的约定更重要。

SQL Server中的标准约定是：

FK_ForeignKeyTable_PrimaryKeyTable

例如，笔记和任务之间的关键是：

FK_note_task

FK_task_user

FK_task_user
FK_note_task
FK_note_user

任务和用户之间的关键是：

FK_note_task

FK_task_user

FK_task_user
FK_note_task
FK_note_user

这为您提供了键中涉及哪些表的“一目了然”视图，因此可以很容易地查看特定表（第一个命名的表）所依赖的表（第二个命名的表）。在这种情况下，完整的密钥集将是：

FK_note_task

FK_task_user

FK_task_user
FK_note_task
FK_note_user

---

因此，您可以看到任务依赖于用户，注释依赖于任务和用户

fk__ForeignKeyTable__PrimaryKeyTable 

这是因为表名本身偶尔会包含下划线字符。这通常遵循约束的命名约定，因为数据元素的名称通常包含下划线字符，例如

CREATE TABLE NaturalPersons (
   ...
   person_death_date DATETIME, 
   person_death_reason VARCHAR(30) 
      CONSTRAINT person_death_reason__not_zero_length
         CHECK (DATALENGTH(person_death_reason) > 0), 
   CONSTRAINT person_death_date__person_death_reason__interaction
      CHECK ((person_death_date IS NULL AND person_death_reason IS NULL)
              OR (person_death_date IS NOT NULL AND person_death_reason IS NOT NULL))
        ...

---

根据此处的答案和注释，包含FK表、FK字段和PK表（FK_FKTbl_FKCol_PKTbl）的命名约定应避免FK约束名称冲突

因此，对于此处给定的表格：

fk_task_userid_user
fk_note_userid_user

所以，如果您添加一列来跟踪上次修改任务或注释的人

fk_task_modifiedby_user
fk_note_modifiedby_user

---

Microsoft关于SQL Server的说明：

外键约束不必仅链接到主键 另一个表中的键约束；它也可以定义为参考 另一个表中唯一约束的列

因此，我将使用术语来描述依赖关系，而不是传统的主要/外部关系术语

当通过依赖（子）表中类似命名的列引用独立（父）表的主键时，我省略了列名：

引用其他列时，或者两个表之间的列名不同，或者只是为了明确起见：

FK_ChildTable_childColumn_ParentTable_parentColumn

---

如果您不经常引用FK并使用MySQL（和InnoDB），那么您可以让MySQL为您命名FK

以后你可以

我通常的做法是

FK_ColumnNameOfForeignKey_TableNameOfReference_ColumnNameOfReference

或者从其他方面来说

FK_ChildColumnName_ParentTableName_ParentColumnName

这样我就可以命名两个外键，它们引用同一个表，就像

历史信息表

中的

列actionBy和actionTo

from

users\u info

表一样

就像

FK_actionBy_usersInfo_name - For actionBy
FK_actionTo_usersInfo_name - For actionTo

注意：

我没有包括子表名，因为这对我来说似乎是常识，我在子表中，所以我可以很容易地假定子表名它的总字符数为26个，非常符合Charles Burns在评论中指出的oracle的30个字符限制

---

读者注意：下面列出的许多最佳实践都不起作用 在Oracle中，由于其名称限制为30个字符。表名或 列名可能已经接近30个字符，因此约定 将两者合并为一个名称需要一个截断标准或 其他技巧查尔斯·伯恩斯

---

这可能太过分了，但对我来说很有效。特别是在处理VLDB时，它对我帮助很大。我使用以下方法：

CONSTRAINT [FK_ChildTableName_ChildColName_ParentTableName_PrimaryKeyColName]

当然，如果出于某种原因您没有引用主键，则必须引用包含在唯一约束中的列，在这种情况下：

CONSTRAINT [FK_ChildTableName_ChildColumnName_ParentTableName_ColumnInUniqueConstaintName]

---

它会很长吗，是的。它是否有助于保持报告信息的清晰，或者让我快速了解潜在问题是在产品警报期间100%希望了解人们对该命名约定的想法

尝试使用大写的版本4 UUID，第一个八位字节替换为FK和''.'（下划线）而不是'-'（破折号）

例如

• FK_4VPO_K4S2_A6M1_RQLEYLT1VQYV

• FK_1786_45A6_A17C_F158C0FB343E

• FK_45A5_4CFA_84B0_E18906927B53

理由如下

• 严格的生成算法=>统一名称
• 密钥长度小于30个字符，这是Oracle中的命名长度限制（12c之前）
• 如果实体名称发生更改，则不需要像基于实体名称的方法那样重命名FK（如果DB支持表重命名运算符）
• 很少使用外键约束的名称。例如，DB工具通常显示约束适用于什么。不需要害怕神秘的外观，因为您可以避免使用它进行“解密”

---

heh-这正是我实际使用的风格（但在camelCase中）-我想我应该在名称中添加一些额外的描述，以说明它们之间的联系。这样至少我们可以阅读彼此的模式；）。。。让人难堪的是，在离开几年后，你自己却无法阅读。我们使用ERWin来绘制模式图，但是有一个文本版本和一个约定通常是很方便的