数据库表定义中的列排序是否有标准/约定？
是否存在关于如何在数据库表的定义中对列进行排序的标准/约定？如果有，该标准的动机是什么？ （优点/缺点）
例如，主键应该是第一列吗？ 外键应该直接跟在主键后面还是应该放在表的最右边？
如果不同 DBMS 的约定之间存在差异，则本例中的 DBMS 是 Microsoft SQL Server 2005。
谢谢 /Erik
Is there a standard/convention for how the columns should be ordered in the definition of a database table, and if so what is the motivation for that standard? (pros/cons)
For example, should the primary key be the first column? Should the foreign keys directly follow the primary key or should they be placed at the far right of the table?
If there is a difference between conventions for different DBMSs, the DBMS in this case is Microsoft SQL Server 2005.
Thanks /Erik
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
我不知道任何标准，但我们构建列的方式是
我们的大型数据列（如注释）放在最后。 它可以更轻松地在查询分析器中查看尽可能多的数据，而无需向右滚动。
I am not aware of any standard, but the way we structure our colums is
Our large data columns, like comments, are put at the end. It makes it easier to view as much data as possible in the Query Analyzer without having to scroll to the right.
我总是这样构造我的表：
I always structure my tables like this:
我不确定设置约定，但我们总是将 ID/主键列作为表中的第一列。 我想这只是因为它让pk看得更清楚。 我想说也遵循 fk 字段，但之后没有真正的标准，你也许可以通过数据类型来做到这一点？
此外，这并不是一个既定的最佳实践，只是个人选择。
I'm not sure about set conventions but we always put the ID/Primary key column as the first column in the table. I suppose it's just because it makes it clearer to see the pk. I'd say also follow that with fk fields but after that there's no real standard, you could maybe do it by datatype?
Also, this isn't a set out best practice, just a personal choice.
据我所知没有。 无论如何，您始终可以在选择期间对列进行重新排序，因此这并不重要，除非您可以通过适当地对列进行排序来对某些数据库进行一些真正晦涩的优化。
None that I know of. You can always re-order the columns during a select anyway, so it hardly matters unless there's some truly obscure optimisation you can do on some databases by ordering your columns appropriately.
据我所知，没有官方标准，但通常的做法是将主键放在第一位（通常是代理项），然后按功能对其他字段进行分组。 因此，在“人员”表中，可以将包含人员地址数据的字段分组在一起。 大多数人在表定义之外添加外键、索引和其他约束。
THere is no official standard that I'm aware of, but the normal practice is to put the primary key first (it's usually a surrogate) and then group the other fields by functionality. So in a "person" table one would group the fields containing the person's address data together. Most people add FKs, indexes and other constraints outside the table definion proper.
嗯.. 据我所知没有任何限制。 这只是一个清晰度问题。
mm.. As I know there are no limitations. Its just a matter of clarity.
我同意上面的大多数帖子，主键优先（至少）。 剩下的就是个人喜好了。 如果你有一个标准，那么就遵守这个标准。
我确实更喜欢将各列按逻辑合理地放在一起。 有时，完全规范化的数据结构并不合适，因此您将“次要实体”存储在同一个表上（即不删除 NULL）。 一个例子是地址字段，或放置在一起的不同电话、移动电话、工作电话列。
我能给出的最引人注目的例子是如何不这样做。 如果开发人员自动生成一个模式，并且列是按字母顺序创建的（甚至 PK 也隐藏在表结构的中间），那么这是最烦人的。
I agree with most of the posts above, primary key first (at least). The rest is personal preference. If you have a standard then keep to that standard.
I do prefer to keep columns fairly logically together. Sometimes a fully normalised data structure is not appropriate so you have "minor entities" stored on the same table (i.e. not removing NULLs). An example would be the address fields, or the different telephone, mobile phone, work phone columns placed together.
The most striking example I can give is HOW NOT TO DO IT. If a developer autogenerates a schema and the columns are created in alphabetical order (and even the PK was hidden in the middle of the table structure) then that is MOST annoying.
根据 edoode：-
另外，
如果您将长度可能不同的列粘贴在表格底部，您将获得微小的性能提升。
As per edoode:-
Plus
You get a teeny weeny ever so slight performance increase if you stick columns that may vary in length at the bottom of the table.