数据库表结构设计 - varchar(n)。N的合适选择

3

作为一个来自C语言背景的人,我可能太过于关注比特和字节,对数据的实际存储方式有些担忧。

尽管如此,我仍然无法避免地考虑到数据是如何存储的,如果我选择一个易于分解为2的幂次方的N,数据库将更有效地打包数据等等。

基于这个“逻辑”,我在一个表中有一个字符串字段,其长度可变,最长为21个字符。出于上述原因,我想使用32而不是21。然而,现在我认为我正在浪费磁盘空间,因为会为11个保证永远不会使用的额外字符分配空间。由于我预计每天要存储数万行数据,所有这些都会累加。

问题:

在考虑到以上所有因素的情况下,我应该声明varchar(21)还是varchar(32),为什么?

[编辑]

存储的数据符合外部规范,并且绝不会超过21个字符。我同时使用MySQL和PostgreSQL,但理想情况下,我希望答案与数据库无关,因为我试图不被任何特定的供应商所束缚。


这个事实永远不会超过21个字符,有多么绝对的限制? - Paddy
1
Varchar代表可变字符,因此选择一个能容纳您想要支持的最大字符串的数字。存储的值将基于实际内容 - 如果只有3个字符,那么该记录列值所使用的磁盘空间也只有3个字符。但它会修剪掉空格... - OMG Ponies
7个回答

4

让数据库实现优化。对于应用程序来说,使用最小的合理大小。

性能通常受到所需磁盘操作数量的影响,数据越小,磁盘操作就越少。一些数据库会进行压缩或公共前缀优化,以使使用的磁盘字节数最少。


2
如果允许列存储超过21个字符,那么有一天,某个小丑(或者可能只是程序错误)可能会加载一个超过21个字符的值,然后就会出现问题。如果他们永远不能在表中存储无效长度的值,那么针对该表的查询将永远不会返回无效长度的值。
哦,而varchar(x)将需要每行/列存储(x+2)个字节,其中额外的2个字节表示实际存储在该行/列中的字符串的长度。

“+2” 参考适用于 SQL Server。你的 RDBMS 里程可能会有所不同。 - Philip Kelley

1

数据是按行存储的,所以决定边界的不仅仅是这个字段的长度。如果行没有填满,SQL也可以留下空白空间。让SQL Server完成它的工作,并根据业务需求定义字段长度。


1
我只能就 SQL Server 发表意见,但如果你总是使用 21 个字符,你应该使用 char(21) 而不是 varchar(21)。 有各种原因,例如:
  1. varchar 每行使用 2 个字节的头部额外存储
  2. 使用 char 确保所有行都是相等长度,这意味着查找数据稍微更快。
  3. 插入表时,varchar 列具有附加偏移量开销。
等等。

我进行了检查,上述所有内容也适用于mySQL。 - Cobusve

0

varchar(n) 只占用存储在列中的数据长度小于n个字符的长度。


0

只需定义您可能需要的最大值。

参见MSDN

存储大小是实际输入数据的字节长度,而不是n个字节。

n仅用于防止您输入超过n个字符。这是对数据库用户的限制。


0

你正在尝试声明的领域有哪些业务规则?如果它从未超过21,那就继续前进。但是,如果你不确定,业务需要你有一定的余地,那么使用32。

请参考此链接


网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接