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


当前回答

我总是使用nvarchar,因为它允许我正在构建的任何东西都能承受我扔给它的几乎所有数据。我的CMS系统使用中文是偶然的,因为我使用了nvarchar。现在,任何新的应用程序都不应该真正关注所需的空间量。

其他回答

我总是使用nvarchar,因为它允许我正在构建的任何东西都能承受我扔给它的几乎所有数据。我的CMS系统使用中文是偶然的,因为我使用了nvarchar。现在,任何新的应用程序都不应该真正关注所需的空间量。

我会说,这取决于情况。

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

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

主要是nvarchar存储Unicode字符,varchar存储非Unicode字符。

“Unicodes”是指16位字符编码方案,允许来自许多其他语言(如阿拉伯语、希伯来语、汉语、日语)的字符在单个字符集中编码。

这意味着unicode使用每个字符2个字节来存储,而非unicode使用每字符一个字节来进行存储。这意味着与非unicode相比,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.

虽然NVARCHAR存储Unicode,但您应该考虑借助于排序,您也可以使用VARCHAR并保存本地语言的数据。

想象一下下面的场景。

DB的排序规则是波斯语,您可以在VARCHAR(10)数据类型中保存一个类似“علی”(阿里的波斯语书写)的值。没有问题,DBMS只使用三个字节来存储它。

但是,如果要将数据传输到另一个数据库并查看正确的结果,则目标数据库必须与目标数据库具有相同的排序规则,在本例中为波斯语。

如果目标排序规则不同,则会在目标数据库中看到一些问号(?)。

最后,请记住,如果您使用的是用于本地语言的大型数据库,我建议您使用位置,而不是使用太多空间。

我相信设计会有所不同。这取决于你工作的环境。