为什么要使用较短的VARCHAR(n)字段？

Question

通常建议选择尽可能窄的数据库字段大小.我想知道这适用于SQL Server 2005 VARCHAR列的程度:在一个VARCHAR(255)字段中存储10个字母的英文单词不会占用比VARCHAR(10)字段更多的存储空间.

是否有其他原因限制VARCHAR字段的大小尽可能贴近数据的大小？我在想

• 性能:在选择,过滤和排序数据时使用较小的n是否有优势？
• 内存,包括在应用程序端(C++)？
• 样式/验证:您认为限制colunm大小以强制非敏感数据导入失败(例如200个字符的姓氏)有多重要？
• 还要别的吗？

背景:我帮助数据集成商将数据流的设计流入数据库支持的系统.他们必须使用限制他们选择的数据类型的API.对于字符数据,只有VARCHAR(n)n <= 255可用; CHAR,NCHAR,NVARCHAR并且TEXT都没有.我们正试图制定一些"良好做法"规则,如果对VARCHAR(255)真正最大尺寸永远不会超过30个字节左右的数据使用甚至存在真正的损害,那么问题就出现了.

一个表的典型数据量是1-10 Mio记录,最多150个属性.查询性能(SELECT通常具有广泛的WHERE子句)和应用程序端检索性能是至关重要的.

Answer 1

1. 数据完整性 - 迄今为止最重要的原因.如果您创建一个名为Surname255个字符的列,您可能会获得多个姓氏.你会得到名字,姓氏,中间名.你会得到他们最喜欢的宠物.你会得到"会计部门的Alice和三角形的头发".简而言之,您将使用户可以轻松地将该列用作notes/surname列.您希望上限阻止尝试将除姓氏之外的内容放入该列的用户.如果你有一个要求特定长度的列(例如美国税收标识符是九个字符)但列是varchar(255),其他开发人员会想知道发生了什么,你也可能得到垃圾数据.

2. 索引和行限制.在SQL Server中,您的IIRC限制为8060字节.有大量数据的大量非varchar(max)列很快就会超出该限制.此外,索引的宽度为IIRC,上限为900字节.因此,如果您想对您的姓氏列和其他包含大量数据的列进行索引,则可能会超出此限制.

3. 报告和外部系统.作为报表设计者,您必须假设如果声明的列的最大长度为255,则可以包含255个字符.如果用户可以这样做,他们就会这样做.因此,要说"它可能不会有超过30个字符." 甚至与"它不能超过30个字符"相同.永远不要依赖前者.作为报表设计者,您必须解决用户将大量数据输入列的可能性.这要么意味着截断值(如果是这样的话,为什么还有额外的空间可用？)或者使用CanGrow来制作一个可爱的报告.无论哪种方式,如果列大小远远超出存储的实际数据,那么在其他开发人员上更难理解列的意图.