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


当前回答

nArchar将帮助您存储Unicode字符。如果您想存储本地化的数据,这是一种方法。

其他回答

varchar适用于存储非unicode,这意味着有限的字符。虽然nvarchar是varchar的超集,所以我们可以使用varchar存储哪些字符,但我们可以在不忽略函数的情况下存储更多字符。

有人评论说,现在存储/空间不是问题。即使空间不是一个问题,确定最佳数据类型也应该是一项要求。

这不仅仅是关于存储!“数据移动”,你就知道我要去哪里了!

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

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

如果您使用的是仅使用ASCII的应用程序,我仍然建议在数据库中使用Unicode。操作系统和数据库排序算法将更好地使用Unicode。Unicode在与其他系统接口时避免了转换问题。你将为未来做准备。您可以始终验证您的数据是否仅限于7位ASCII,无论您要维护的是什么遗留系统,即使您享受完全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,因为它允许我正在构建的任何东西都能承受我扔给它的几乎所有数据。我的CMS系统使用中文是偶然的,因为我使用了nvarchar。现在,任何新的应用程序都不应该真正关注所需的空间量。

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

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

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

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