是否存在数据库表定义中列的排序的标准/约定？

Question

是否有关于如何在数据库表的定义中对列进行排序的标准/约定，如果是，那么该标准的动机是什么？ （优点/缺点）

例如，主键应该是第一列吗？外键是应该直接跟在主键之后还是应该放在表的最右边？

如果不同DBMS的约定存在差异，则本例中的DBMS为Microsoft SQL Server 2005。

谢谢/ Erik

Answer 1

我不知道任何标准，但我们构建我们的colums的方式是

1. 主键
2. 任何外键
3. 数据

我们的大型数据列（如注释）将放在最后。它使查询分析器中的数据尽可能多，而无需向右滚动。

Answer 2

我总是像这样构建我的表：

1. 主键
2. '跟踪'列（DateModified，ModifiedBy等）
3. 任何外键
4. 数据

Answer 3

我不确定设置约定，但我们始终将ID /主键列作为表中的第一列。我想这只是因为它更清楚地看到了PK。我会说跟fk字段一样，但之后没有真正的标准，你可以用数据类型来做吗？

此外，这不是一个最佳实践，只是个人选择。

Answer 4

我不知道。无论如何，您总是可以在选择期间重新排序列，因此除非通过对列进行适当排序，您可以对某些数据库进行一些真正模糊的优化，这几乎无关紧要。

Answer 5

这不是我所知道的官方标准，但通常的做法是首先放置主键（通常是代理），然后按功能对其他字段进行分组。因此，在“人”表中，可以将包含人的地址数据的字段组合在一起。大多数人在表格定义之外添加FK，索引和其他约束。

Answer 6

mm ..据我所知，没有任何限制。这只是一个清晰的问题。

Answer 7

我同意上面的大多数帖子，首先是（至少）主键。其余的是个人喜好。如果您有标准，那么请遵守该标准。

我更喜欢将列保持在逻辑上。有时，完全规范化的数据结构是不合适的，因此您将“次要实体”存储在同一个表中（即不删除NULL）。一个例子是地址字段，或者放在一起的不同电话，移动电话，工作电话列。

我能给出的最引人注目的例子是如何做到这一点。如果开发人员自动生成模式并且按字母顺序创建列（甚至PK隐藏在表结构的中间）那么这很烦人。

Answer 8

根据edoode： -

Primary key(s) 
'Tracking' columns (DateModified, ModifiedBy and such) 
Any foreign keys 
Data 

加

Fixed width 'not null' columns
Fixed width 'nullable' columns
Variable Width columns VARCHAR NVARCHAR etc.
CLOBS
BLOBS 

如果您在表格的底部粘贴长度可能不同的列，那么您的性能会略有提升。