这可能是一个愚蠢的问题，但这里有：
是否有标准或最佳实践，它指定表中的外键列应按什么顺序排列？
我想知道PK是表中的第一列，然后是所有外键，然后是与该表相关的列。
其他方法是将PK作为第一列，然后是所有支持列，然后是所有外键...
我想这真的没关系，但我想为我的组织制定一个标准......
答案 0 :(得分：3)
丝毫没关系，我认为最重要的是你如何命名列。确保外键都遵循某种惯例，这将使您在开发过程中更轻松。
例如，为所有外键或类似内容添加_fk后缀。
因此，当用作外键时，vehicle_id变为vehice_id_fk。
答案 1 :(得分：2)
我工作的地方，我先看过PK，然后是外键，然后是数据。但DRL是对的;没关系。指定多列索引的顺序至关重要，但不是指定表中列的顺序。如果使用_fk或_key或_id或类似约定为外键列名添加后缀，则可以为您和您的后继者节省时间。
答案 2 :(得分：2)
同意DRL。添加新列时，很难维护基于列排序的约定。此外，大多数数据库客户端将能够为您提供列和列表的列表（PK，FK等）。
答案 3 :(得分：2)
表中外键列的顺序不是，也不应该是相关的。我见过的最好的标准（随着时间的推移逐渐降低，自然是）：
此类实施的目标是更新所需的登录量。
从演示的角度来看，一个体面的ERD工具应该在列和“行”级别呈现外键引用。
另外，我不遵循我之前看到的建议 - 例如VEHICLE_ID_FK。只需将VEHICLE_ID放在VEHICLE表的子表中，然后继续。如果您需要多个VEHICLE_ID列，请对它们进行适当的类型转换，例如COPS_VEHICLE_ID和ROBBERS_VEHICLE_ID。
答案 4 :(得分：1)
有趣的想法，但就个人而言，我认为为此制定“整个组织的标准”会带来更多弊大于利。
培训和最佳实践听起来不错，但盲目执行的规则“被视为有害”。
答案 5 :(得分：1)
我建议，最好不要有这样的规则。 “规则适合傻瓜。”
如果您确实引入了这样的规则，有人想要添加新密钥，会发生什么？或者向现有密钥添加新列？他们应该重新排列所有列吗？我看不出你从中获得了什么。
理想情况下，您的列应该被命名，以便明确其中的内容。这并不容易，而且从长远来看，一点点额外的想法会自我回报。