10

许多数据库模式似乎遵循以下标准：

(2^n)-1对于大字段：

varchar(511)
varchar(255)
varchar(127)

...然后(2^n)用于较小的

varchar(64)
varchar(32)
varchar(16)
varchar(8)

我理解为什么使用 (2^n)-1 的数字，我不明白为什么没有必要将趋势延续到小领域。

例如

varchar(63)
varchar(31)
varchar(15)
varchar(7)

这是有原因的，还是只是回报减少得太多了？

4

6 回答 6

9

我记得以前，当使用 2^n 长度更好地对齐磁盘或内存上的块时。对齐的块更快。今天，“块”大小更大，内存和磁盘足够快，可以忽略对齐，除了非常大的块。（无论“非常大”在今天意味着什么......）

如今，这样做只是传统的做法。

还有一个原因是我成为那句名言：世上只有 10 种人：会二进制的人和其他人。

并且 2^n -1 是梅森素数的候选者。所以它也很怪...

于 2009-10-15T09:39:29.477 回答
7

我认为这只是程序员在无关紧要时从空中挑选一个数字。

例如，如果您必须对“注释”字段进行限制，非程序员可能会选择 100 或 200 个字符作为整数，而程序员可能会将 127 或 255 视为整数。

于 2009-10-15T09:39:11.803 回答
3

我不能说，因为我已经看到“-1”趋势在较小/较大字段中的使用方式不同。但是我认为这只不过是开发人员/dba 强迫症。当他们真的应该根据业务规则而不是“漂亮”做出字段长度决定时，总是想要“整数”

于 2009-10-15T09:27:44.023 回答
2

不仅回报减少了，而且如果您设置具有任意限制的字符串类型，您更有可能导致问题而不是解决问题。

如果它确实是业务约束，则使用 TEXT 类型（或类似类型）和长度上的 CHECK 约束，并根据您要强制执行的业务约束选择数字。

无论如何，DBMS 可能会以与 varchar(x) 相同的方式实现 TEXT 类型的存储。如果没有，并且您真的很在意，您应该调查特定系统的内部存储策略，并考虑 varchar 是否有任何好处。

于 2009-10-15T17:03:07.743 回答
0

其实我还是第一次听说这样的“趋势”。我的 varchar 字段总是只要我需要它们。

我会说这背后没有特别的原因。只是开发者的偏好。

于 2009-10-15T09:27:53.633 回答
0

我一时无法想象他们为什么要以 2^N 或 2^N-1 的方式来调整字段的大小。从 SQL Server 的角度来看，这听起来更像是对 SQL 如何在页面级别存储数据的误解，而不是具体原因。

我会更关注类型、潜在的页外存储 (SLoB / LoB) 和行/页 + 通过大小调整满足业务需求，而不是基于使用 2^N 等的公式

于 2009-10-15T09:31:38.127 回答