订购数据库表中的列

Question

当涉及到DB表中的列顺序时,是否有任何标准或至少是最佳实践？

这是我遵循的手工制作的惯例:

• 主键(即id);
• 唯一列(即email,ssn);
• 外键(即article);
• 列保持用户生成的数据(即first_name,last_name);
• 保持系统生成数据的列;
  • 非布尔(即password_hash);
  • 布尔型(即deleted,verified)
• 时间戳列(即created_at);

但是,这些问题仍未解决,所以我想听听你的想法.

Answer 1

简而言之,您已经很好地阐述了标准惯例,并且您没有错过很多.国际海事组织,唯一让人看起来不专业的举动就是首先没有主键.在那之后拥有外键是一个很好的约定,但不是什么大不了的事.(包含外键的多字段主键当然应该处于开头阶段,或者有人应该被打败.)我还要添加两个额外的想法:

1. 具有相似主题的字段彼此靠近.例如,将City/State/Zip字段分开是没有用的.我认为,无论user_role还是user_ip是第一位的,都是最重要的,但听起来它们应该是彼此相邻的.
2. 除了其他此类惯例之外,对于按字母顺序排列的内容并不会有任何损害.

在数据库中有额外的约定是一个非常好的主意(就像你提到的那样总是在最后有时间戳).如果你在很多表中都有ChangeDate和ChangeBy字段,那么将它们(彼此相邻并且一致)放在一起就是好的.

另外,ErikE提到在表的末尾可以有一些效率,它们可能经常包含空值的可变长度字段(varchar,nvarchar).除此之外,我不认为在现代关系数据库中以某种方式安排事物有任何性能优势.

命名

通常,当您决定列顺序时,您决定列名称,所以我想稍微解决一下.你可以通过命名你的领域来制造可怕的,代价高昂的错误; 这比列排序重要得多.订购可以很容易地改变,但糟糕的名字将永远导致你的问题.一年后更改表/列名称是十分痛苦的,因为有十几个引用它们.我刚刚在这里添加了一个答案来解决这个非常重要的话题.

Answer 2

在MSSQL Server中,列列表末尾的NULL列实际上减少了存储该行所需的空间,这可以增加每页的行数,这可以减少每次I/O操作所需的读取次数,这是一个绩效收益.虽然性能优势可能不是很大,但对于具有优势NULL值的任何列,都要记住这一点.

解密SQL Server数据页面可以获得减少存储空间的尾随NULL的证明:

...空位图略有不同(fe/1111 1110),因为它现在是第二列的空值.有趣的是,在这一行中,只有一个可变长度列,而不是两个.因此,只有一个可变长度列结束索引标识符,0d00/0x000d/13.从中我们可以得出结论,按顺序处理列,因此如果特定列通常为null,则可能需要考虑列的顺序,最后订购可能更有效率.

请注意,这仅适用于可变长度列.虽然这显然包括varchar,varbinary等,但我不确定其他数据类型(并且现在没有时间来最终确定这一点).