为什么仍然有varchar数据类型？

我的许多数据库都有定义为varchars的字段。这一直没有大的问题，因为我生活和工作在美国（其中存在的唯一语言是“美国”。啊哈）

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

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

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

但是，今天的用户如果想节省存储空间，则可以定义其nvarchars将数据存储为UTF-8而不是默认的UTF-16。如果主要需要的话，这将允许8位编码，同时确保插入到其DB中的2-8字节罕见字符不会破坏任何内容。

我想念什么吗？在过去的15到20年中，这种情况没有发生变化，这是否有充分的理由？

1. varchar的工作足以应付许多西欧语言（挪威语，丹麦语，德语，法语，荷兰语等），但会遇到一些整理问题

2. 在SO上查看此内容varchar vs nvarchar性能 nvarchar具有严重的性能影响

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

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

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

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

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

这正是大多数开源数据库所使用的VARCHAR。

• MySQL提供utf8和ucs2“排序规则”。
• SQLite使您可以在UTF-8（默认）和UTF-16之间进行选择。
• PostgreSQL支持UTF-8（但不支持UTF-16）。

无需具有两个单独的字符串类型。

Microsoft认为8位字符串用于传统编码，而Unicode = UTF-16，这是一个奇怪的说法。这可能是相关的Windows API本身处理char和wchar_t这种方式。

因为我们中的某些人在不需要Unicode功能的最新硬件上构建了更轻，更小的应用程序。也许我们以后需要更改它，但是就目前而言，我们根本不需要它。我喜欢我的琴弦在NVARCHAR下占据它们原本需要的1/2的空间。