我的许多数据库都有定义为varchars的字段。自从我在美国生活和工作(存在的唯一语言是“美国”)以来,这就没什么大问题了。

使用数据库大约5年后,我发现最终,我遇到了varchar字段性质有限的问题,我不得不修改字段以将数据存储为nvarchars。在不得不对表进行另一次更新,将varchar字段转换为nvarchar之后,我有了一个想法-为什么我们仍要这样做呢?我很早就做出了将所有新的文本字段都定义为nvarchar而不是varchar的决定,这是我10年前上学时从课本中学到的。

是2011年,去年有一个新版本的SQL Server。当可以/应该使用nvarchar时,为什么为什么继续支持varchar数据类型?

我知道,经常有人争辩说nvarchars是varchars的“两倍大”,因此存储空间的使用可能是维护varcars的观点之一。

但是,今天的用户如果想节省存储空间,可以定义其nvarchars将数据存储为UTF-8而不是默认的UTF-16。如果主要需要的话,这将允许进行8位编码,同时确保插入到其DB中的罕见2-8字节字符不会破坏任何内容。

我错过了什么吗?在过去15到20年中这种情况没有发生变化,这是否有充分的理由?

#1 楼


varchar的工作足以应付许多西欧语言(挪威语,丹麦语,德语,法语,荷兰语等),但会遇到一些归类问题
在SO上查看此内容varchar vs nvarchar性能nvarchar的性能很出色含义
与处理日期MDY和DMY相比,这是微不足道的


#2 楼

除了解决标准和兼容性的答案外,还应牢记性能。尽管人们很容易接受磁盘空间便宜,但是DBA /开发人员经常忽略这样一个事实,即查询性能有时与表的行/页大小直接相关。使用NVARCHAR而不是VARCHAR(必要时)将有效地使字符字段的行大小加倍。如果您有5个或10个50个长度的字段,那么您正在谈论可能在每行增加500个字节。如果您有一张宽桌子,这可能会将每一行推到多页中,并对性能产生不利影响。

#3 楼

仍然有大量组织使用假定为单字节字符的应用程序,接口,平台和工具建立了庞大的基础。数据库很少孤立存在-它们是IT生态系统的一部分。如果您有成千上万个依赖于单字节字符的组件和数百万行代码,那么您将有充分的理由投资切换到unicode所需的时间和金钱。这种规模的变更可能需要数年才能完成。在某些地方,Unicode还是相对较新,很少见或不完全受支持的。

VARCHAR和NVARCHAR都是ISO标准SQL的一部分。删除或弃用SQL Server中的VARCHAR支持将是兼容性和可移植性方面的倒退。

#4 楼


或者,今天的用户如果想节省存储空间,则可以定义其nvarchars将
数据存储为UTF-8而不是默认的UTF-16。


这正是大多数开源数据库对VARCHAR所做的工作。




MySQL提供了utf8ucs2“排序规则”。

SQLite允许您在UTF-8(默认值)和UTF-16之间选择。

PostgreSQL支持UTF-8(但不支持UTF-16)。

否需要具有两种单独的字符串类型。

微软很奇怪,因为它认为8位字符串用于旧式编码,而Unicode = UTF-16。这可能与Windows API本身以这种方式处理charwchar_t有关。

#5 楼

因为我们中的某些人在不需要Unicode功能的最新硬件上构建了更轻,更小的应用程序。也许我们稍后需要更改它,但是就目前而言,我们根本不需要它。我希望我的琴弦占据NVARCHAR下原本需要的空间的1/2。