只是nvarchar支持多字节字符吗?如果是这样的话,除了存储问题之外,使用varchars真的有什么意义吗?


当前回答

遵循Sql Server VARCHAR和NVARCHAR数据类型之间的差异。在这里,你可以看到一个非常描述性的方式。

一般来说,varchar将数据存储为Unicode,因此,如果要在数据列中存储多语言数据(多种语言),则需要N变量。

其他回答

我不得不在这里说(我意识到我可能会打开自己的心扉!),但NVARCHAR确实比VARCHAR更有用(注意更多!)的唯一时间是,所有从属系统上的所有排序规则和数据库本身都是相同的。。。?如果没有,那么无论如何都必须进行排序规则转换,因此VARCHAR和NVARCHAR一样可行。

除此之外,一些数据库系统,如SQL Server(2012年之前)的页面大小约为8K。因此,如果您要存储未保存在TEXT或NTEXT字段中的可搜索数据,那么VARCHAR提供了8k的完整空间,而NVARCHAR仅提供4k(双倍字节,双倍空间)。

总之,我想,两者的使用取决于:

项目或上下文基础设施数据库系统

我会说,这取决于情况。

如果您开发一个桌面应用程序,其中操作系统以Unicode(与所有当前的Windows系统一样)工作,并且语言本身支持Unicode(默认字符串为Unicode,如Java或C#),那么使用nvarchar。

如果您开发了一个web应用程序,其中字符串以UTF-8形式出现,语言为PHP,而PHP本身仍然不支持Unicode(在5.x版本中),那么varchar可能是一个更好的选择。

nvarchar列可以存储任何Unicode数据。varchar列限制为8位代码页。有些人认为应该使用varchar,因为它占用更少的空间。我认为这不是正确的答案。代码页不兼容性是一个难题,Unicode是解决代码页问题的良方。现在磁盘和内存都很便宜,真的没有理由再浪费时间摆弄代码页了。

所有现代操作系统和开发平台都在内部使用Unicode。通过使用nvarchar而不是varchar,可以避免每次读取或写入数据库时进行编码转换。转换需要时间,而且容易出错。从转换错误中恢复是一个非常重要的问题。

如果您使用的是仅使用ASCII的应用程序,我仍然建议在数据库中使用Unicode。操作系统和数据库排序算法将更好地使用Unicode。Unicode在与其他系统接口时避免了转换问题。你将为未来做准备。您可以始终验证您的数据是否仅限于7位ASCII,无论您要维护的是什么遗留系统,即使您享受完全Unicode存储的一些好处。

如果使用单个字节存储字符,则有256种可能的组合,因此可以保存256种不同的字符。排序规则是一种模式,它定义了字符及其进行比较和排序的规则。

1252,即拉丁语1(ANSI),是最常见的。单字节字符集也不足以存储许多语言使用的所有字符。例如,一些亚洲语言有数千个字符,因此每个字符必须使用两个字节。

Unicode标准

当在网络中使用使用多个代码页的系统时,管理通信变得困难。为了实现标准化,ISO和Unicode联盟引入了Unicode。Unicode使用两个字节来存储每个字符。也就是说,可以定义65536个不同的字符,所以几乎所有的字符都可以被Unicode覆盖。如果两台计算机使用Unicode,每个符号都将以相同的方式表示,不需要转换-这就是Unicode背后的想法。

SQL Server有两类字符数据类型:

非Unicode(char、varchar和文本)Unicode(nchar、nvarchar和ntext)

如果我们需要保存来自多个国家的字符数据,请始终使用Unicode。

varchar仅用于非Unicode字符,而nvarchar用于Unicode和非Unicode字符。下面给出了它们之间的一些其他差异。

VARCHAR与NVARCHAR

VARCHAR NVARCHAR
Character Data Type Variable-length, non-Unicode characters Variable-length, both Unicode and non-Unicode characters such as Japanese, Korean, and Chinese.
Maximum Length Up to 8,000 characters Up to 4,000 characters
Character Size Takes up 1 byte per character Takes up 2 bytes per Unicode/Non-Unicode character
Storage Size Actual Length (in bytes) 2 times Actual Length (in bytes)
Usage Used when data length is variable or variable length columns and if actual data is always way less than capacity Due to storage only, used only if you need Unicode support such as the Japanese Kanji or Korean Hangul characters.