为什么仍然存在varchar数据类型？

Question

我的许多数据库都将字段定义为varchars。自从我在美国生活和工作以来，这并不是什么大问题(在美国，唯一存在的语言是“美国人”)。(嗯哼)

在使用数据库大约5年之后，我发现我最终遇到了varchar字段的局限性问题，我不得不修改我的字段以将数据存储为nvarchars。在不得不对表进行另一次更新之后，将varchar字段转换为nvarchar之后，我就想到了--我们为什么还要这样做呢？很久以前，我就决定把所有新的文本字段定义为nvarchar，而不是varchar，这是我10年前上学时从课本上学到的。

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

我知道，人们经常认为，nvarchars是varchars的“两倍”，所以存储空间的使用可能是维护varchars的争论之一。

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

我是不是遗漏了什么？在过去的15到20年里，这种情况没有改变，有什么好的理由吗？

Answer 1

1. 对于许多西欧语言(挪威语、丹麦语、德语、法语、荷兰语等)来说，varchar的作品已经足够好了。
2. 请参见此，因此varchar与nvarchar性能 nvarchar具有严重的性能影响。
3. 与处理日期MDY和DMY相比，这是微不足道的。

Answer 2

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

Answer 3

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

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