表中外键列位置的最佳实践答案

【问题标题】：Best Practice for Foreign Key column position in table表中外键列位置的最佳实践
【发布时间】：2010-07-06 01:14:31
【问题描述】：

这可能是一个愚蠢的问题，但这里是：

是否有描述 mssql 表中外键列顺序的标准或最佳实践？

我喜欢这样的想法，即 PK 是表中的第一列，然后是所有外键，然后是与该表相关的所有其他列。

另一种方法是将 PK 作为第一列，然后是所有支撑列，然后是所有外键...

我想这真的没关系，但我想在我的组织中制定一个标准。

【问题讨论】：

最好让您的组织使用的表架构图或列表以一致的方式排序（先 pk 然后 fks，或者 pks 采用一种颜色/字体，fks 采用另一种... )，这是对命名约定的补充。
当您从头开始构建新表时，可能会作为建议使用 - 但随着时间的推移维护它几乎是不可能的。另外：根据定义，列排序在关系数据库中是无关紧要的——毕竟我们只是在谈论无序元组。所以不要在真正不成问题的事情上投入太多精力。
表示表的主键、候选键和外键的列（记住每一个都可以是跨多列的组合）可以重叠，因此您的标准需要非常具体......但它会实现什么，我想知道？
如果设计得当，计算机可能不太关心您将列放置在什么顺序。但是，人类并不擅长探索数据结构，因此以一致且可识别的模式对它们进行排序会大有帮助新手了解您的数据库。

【解决方案1】：

一点都不重要，我认为最重要的是如何命名列。确保外键都遵循某种约定将使您在开发时更轻松。

例如为所有外键或类似的东西添加一个 _fk 后缀。

所以vehice_id在用作外键时变成vehice_id_fk。

【讨论】：

【解决方案2】：

在我工作过的地方，我首先看到了 PK，然后是外键，然后是数据。但是 DRL 是对的；没关系。指定多列索引的顺序很重要，但在表中指定列的顺序并不重要。如果您使用 _fk 或 _key 或 _id 或类似约定为外键列名称添加后缀，它将为您和您的继任者节省时间。

【讨论】：

【解决方案3】：

同意 DRL。随着新列的添加，基于列排序的约定将难以维护。此外，大多数 db 客户端都可以为您提供列列表及其名称（PK、FK 等）。

【讨论】：

【解决方案4】：

表中外键列的顺序不相关，也不应该相关。我见过的最好的标准（随着时间的推移自然会降低）：

这种实现的目标是更新所需的日志记录量。

从表示的角度来看，一个不错的 ERD 工具应该在列和“行”级别上显示外键引用。

另外，我不会遵循我之前看到的建议 - 例如。 VEHICLE_ID_FK。只需将 VEHICLE_ID 放入 VEHICLE 表的子表中，然后继续。如果您需要多个 VEHICLE_ID 列，请对它们进行适当的类型转换，例如 COPS_VEHICLE_ID 和 ROBBERS_VEHICLE_ID。

【讨论】：

【解决方案5】：

有趣的想法，但我个人认为为此制定“整个组织的标准”弊大于利。

培训和最佳做法听起来不错，但盲目执行规则“被认为有害”。

【讨论】：

我之所以想先查看所有外键，是因为我们的一些表有很多列，所以在进行选择时更容易弄清楚发生了什么以及所有的首先列出外键..这是我考虑引入这样一个规则的唯一原因..l :)
@coxymla：编码约定通常是一件好事。但我承认，任何此类政策都可能存在边缘情况，最好是破例。
是的，我当然不反对编码约定！只是这个我真的看不出来重点。会有一些表格可能特别适合约定，也可能有一些表格不太适合。但是强制执行规则对 IMO 没有帮助。

【解决方案6】：

我建议最好不要有这样的规则。 “规则是为傻瓜准备的。”

如果您确实引入了这样的规则，并且有人想添加新密钥，会发生什么？或者向现有键添加新列？他们是否应该重新排列所有列来这样做？我看不出你能从中得到什么。

理想情况下，您的列应该命名，以便清楚其中的内容。这并不容易，从长远来看，多做一点思考就会得到回报。

【讨论】：