外键命名方案

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

根据这些表格:

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

在任务具有备注的情况下，任务由用户拥有，而用户编写备注。

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

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

135940 次浏览
小开

FK_TABLENAME_COLUMNNAME呢？

只要有可能，就尽量简化 是的。

小开

我通常只是将我的 PK 命名为 id，然后在其他表中命名 FK 时将我的表名和键列名连接起来。我从不使用驼峰式大小写，因为有些数据库放弃了大小写敏感性，而只是返回所有大小写名称。不管怎样，这就是我设计的你们桌子的样子:

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

请注意，我还使用单数来命名表，因为一行表示我要持久化的对象之一。这些约定中的许多都是个人偏好。我认为，选择一个惯例并始终使用它，比采用别人的惯例更为重要。

小开
最佳答案

SQLServer 中的标准约定是:

FK_ForeignKeyTable_PrimaryKeyTable

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

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 关于 SQLServer 的说明:

FOREIGNKEY 约束不必只链接到主要成员 另一个表中的 KEY 约束; 也可以定义为引用 另一个表中 UNIQUE 约束的列。

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

当通过 受养人(子女)表中类似命名的列引用 独立(父母)表的 PRIMARYKEY 时，我省略了列名:

FK_ChildTable_ParentTable

当引用其他列时，或者列名在两个表之间有所不同，或者仅仅是为了明确起见:

FK_ChildTable_childColumn_ParentTable_parentColumn
小开

如果你不经常使用 MySQL (和 InnoDB)来引用你的 FK，那么你可以让 MySQL 为你命名 FK。

在以后的时间你可以 通过运行查询找到您需要的 FK 名称。

小开

我通常的做法是

FK_ColumnNameOfForeignKey_TableNameOfReference_ColumnNameOfReference

或者换句话说

FK_ChildColumnName_ParentTableName_ParentColumnName

通过这种方式，我可以命名两个引用同一个表的外键，比如 history_info table和 users_info表中的 column actionBy and actionTo

就像

FK_actionBy_usersInfo_name - For actionBy
FK_actionTo_usersInfo_name - For actionTo

请注意:

我没有包含子表名，因为对我来说这似乎是常识，我在子表中，所以我可以很容易地假设子表的名称。这是由查尔斯伯恩斯在评论 给你

读者注意: 下面列出的许多最佳实践都不起作用 因为它的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 工具通常显示约束应用于什么。没有必要害怕神秘的看，因为你可以避免使用它的“解密”。

提交答案