为什么还有 varchar 数据类型？

Question

我的许多数据库都有定义为 varchars 的字段。自从我在美国生活和工作以来，这并不是什么大问题（那里唯一存在的语言是“美国”。咳咳）

在使用数据库大约 5 年后，我发现我最终遇到了 varchar 字段的有限性质的问题，我必须修改我的字段以将数据存储为 nvarchars。在不得不对表进行另一次更新，将 varchar 字段转换为 nvarchar 之后，我有了一个想法——为什么我们仍然这样做？我早就决定将所有新的文本字段定义为 nvarchar，而不是 varchar，这是我 10 年前在学校时从教科书中学到的。

现在是 2011 年，去年发布了新版本的 SQL Server。当我们可以/应该使用 nvarchar 时，为什么我们继续支持 varchar 数据类型？

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

但是，今天的用户如果想节省存储空间，可以定义他们的 nvarchars 以将数据存储为 UTF-8 而不是默认的 UTF-16。如果主要需要，这将允许 8 位编码，同时保证插入到他们的数据库中的稀有 2-8 字节字符不会破坏任何东西。

我错过了什么吗？在过去的 15 到 20 年里，这是否有充分的理由没有改变？

Answer 1

1. varchar 工作对于许多西欧语言（挪威语、丹麦语、德语、法语、荷兰语等）来说已经足够好了，但存在一些整理问题

2. 请参阅 SO varchar vs nvarchar 性能nvarchar对性能有严重影响

3. 与处理日期 MDY 与 DMY 相比，这是微不足道的

Answer 2

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

Answer 3

许多组织仍然拥有大量采用单字节字符的应用程序、接口、平台和工具。数据库很少孤立存在——它们是 IT 生态系统的一部分。如果您有数以千计的组件和数百万行依赖于单字节字符的代码，那么您需要有充分的理由投入时间和金钱来切换到 unicode。这种规模的变化可能需要数年时间才能完成。在某些地方，Unicode 仍然相对较新、很少见或没有得到完全支持。

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

Answer 4

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

这正是大多数开源数据库使用VARCHAR.

• MySQL的规定utf8和ucs2“归类”。
• SQLite为您提供了 UTF-8（默认值）和 UTF-16 之间的选择。
• PostgreSQL支持 UTF-8（但不支持 UTF-16）。

不需要有两个单独的字符串类型。

微软是一个奇怪的人，它认为 8 位字符串用于遗留编码并且 Unicode = UTF-16。这可能是相关的Windows API本身处理char和wchar_t这种方式。

Answer 5

因为我们中的一些人在不需要 Unicode 功能的不太先进的硬件上构建更轻、更小的应用程序。也许我们稍后需要更改它，但现在，我们根本不需要它。我喜欢我的字符串占用 1/2 的空间，否则它们必须在 NVARCHAR 下使用。