它只是nvarchar
支持多字节字符吗?如果是这样,除了存储问题之外,使用真的有什么意义吗varchars
?
列nvarchar
可以存储任何 Unicode 数据。列varchar
限制为 8 位代码页。有些人认为varchar
应该使用它,因为它占用的空间更少。我相信这不是正确的答案。代码页不兼容是一种痛苦,而 Unicode 是解决代码页问题的良方。现在有了便宜的磁盘和内存,真的没有理由再浪费时间处理代码页了。
所有现代操作系统和开发平台都在内部使用 Unicode。通过使用nvarchar
rather than varchar
,您可以避免每次读取或写入数据库时都进行编码转换。转换需要时间,而且容易出错。从转换错误中恢复是一个非常重要的问题。
如果您正在与仅使用 ASCII 的应用程序交互,我仍然建议在数据库中使用 Unicode。操作系统和数据库整理算法将更好地与 Unicode 配合使用。Unicode 避免了与其他系统交互时的转换问题。你将为未来做准备。对于您必须维护的任何遗留系统,您始终可以验证您的数据是否仅限于 7 位 ASCII,甚至在享受完整 Unicode 存储的一些好处时也是如此。
varchar:可变长度的非 Unicode 字符数据。数据库排序规则确定使用哪个代码页存储数据。
nvarchar:可变长度的 Unicode 字符数据。依赖于数据库排序规则进行比较。
了解这些知识后,请使用与您的输入数据匹配的任何一个(ASCII 与 Unicode)。
我总是使用 nvarchar,因为它允许我正在构建的任何东西都能承受我扔给它的几乎所有数据。我的 CMS 系统偶然出现了中文,因为我使用了 nvarchar。如今,任何新的应用程序都不应该真正关心所需的空间量。
这取决于 Oracle 的安装方式。在安装过程中,设置了 NLS_CHARACTERSET 选项。您也许可以通过查询找到它SELECT value$ FROM sys.props$ WHERE name = 'NLS_CHARACTERSET'
。
如果您的 NLS_CHARACTERSET 是像 UTF8 这样的 Unicode 编码,那很好。VARCHAR 和 NVARCHAR 的使用几乎相同。现在停止阅读,去读吧。否则,或者如果您无法控制 Oracle 字符集,请继续阅读。
VARCHAR — 数据以 NLS_CHARACTERSET 编码存储。如果同一台服务器上还有其他数据库实例,你可能会被它们限制;反之亦然,因为您必须共享设置。这样的字段可以存储任何可以使用该字符集编码的数据,除此之外别无其他。因此,例如,如果字符集是 MS-1252,则您只能存储英文字母、一些重音字母和其他一些字符(如 € 和 —)。您的应用程序仅对少数地区有用,无法在世界其他任何地方运行。因此,它被认为是一个坏主意。
NVARCHAR — 数据以 Unicode 编码存储。支持每种语言。一个好主意。
存储空间呢?VARCHAR 通常是高效的,因为字符集/编码是为特定语言环境定制设计的。NVARCHAR 字段以 UTF-8 或 UTF-16 编码存储,具有讽刺意味的是,基于 NLS 设置。UTF-8 对于“西方”语言非常有效,同时仍然支持亚洲语言。UTF-16 对于亚洲语言非常有效,同时仍然支持“西方”语言。如果担心存储空间,请选择 NLS 设置以使 Oracle 根据需要使用 UTF-8 或 UTF-16。
处理速度怎么样?大多数新的编码平台本机使用 Unicode(Java、.NET,甚至是多年前的 C++ std::wstring!)因此,如果数据库字段是 VARCHAR,它会强制 Oracle 在每次读取或写入时在字符集之间进行转换,这不太好。使用 NVARCHAR 可避免转换。
底线:使用 NVARCHAR!它避免了限制和依赖性,适用于存储空间,而且通常也最适合性能。
nvarchar 将数据存储为 Unicode,因此,如果您要在数据列中存储多语言数据(不止一种语言),则需要 N 变体。
varchar
仅用于non-Unicode characters
另一方面nvarchar
用于两者unicode
和non-unicode
字符。下面给出了它们之间的其他一些区别。
VARCHAR 与 NVARCHAR
变量 | NVARCHAR | |
---|---|---|
字符数据类型 | 可变长度、非 Unicode 字符 | 可变长度,包括 Unicode 和非 Unicode 字符,例如日文、韩文和中文。 |
最大长度 | 取决于8,000 characters |
取决于4,000 characters |
字符大小 | 占用1 byte 每个字符 |
占用2 bytes 每个 Unicode/非 Unicode 字符 |
存储空间 | 实际长度(以字节为单位) | 实际长度的 2 倍(以字节为单位) |
用法 | 当数据长度是可变的或可变长度的列时使用,如果实际数据总是远小于容量 | 由于仅用于存储,仅在需要 Unicode 支持(例如日文汉字或韩文韩文字符)时使用。 |
Varchar(n)
和之间的主要区别nvarchar(n)
是:
Varchar
(可变长度,非 Unicode 字符数据)大小最大为 8000。
- 它是一种可变长度数据类型
- 用于存储非Unicode字符
- 每个字符占用1个字节的空间
Nvarchar
: 可变长度的 Unicode 字符数据。
- 它是一种可变长度数据类型
- 用于存储 Unicode 字符。
- 数据以 Unicode 编码存储。支持每种语言。(例如阿拉伯语、德语、印地语等语言)
我的两分钱
如果未使用正确的数据类型,索引可能会失败:
在 SQL Server 中:当您在 VARCHAR 列上建立索引并向其提供 Unicode 字符串时,SQL Server 不会使用该索引。当您将 BigInt 呈现给包含 SmallInt 的索引列时,也会发生同样的事情。即使 BigInt 小到可以成为 SmallInt,SQL Server 也无法使用索引。反过来,您没有这个问题(当向索引的 BigInt ot NVARCHAR 列提供 SmallInt 或 Ansi-Code 时)。不同 DBMS(数据库管理系统)之间的数据类型可能不同:
要知道每个数据库的数据类型都略有不同,并且 VARCHAR 并不意味着到处都一样。SQL Server 有 VARCHAR 和 NVARCHAR,而 Apache/Derby 数据库只有 VARCHAR,而 VARCHAR 在 Unicode 中。
主要是nvarchar存放Unicode字符,varchar存放非Unicode字符。
“Unicodes”是指 16 位字符编码方案,允许将来自许多其他语言(如阿拉伯语、希伯来语、中文、日语)的字符编码在一个字符集中。
这意味着 unicodes 每个字符使用 2 个字节来存储,而 nonunicodes 每个字符仅使用一个字节来存储。这意味着与非 unicode 相比,unicode 需要双倍的存储容量。