sql-server - max长度 - sql server varchar nvarchar区别




VARCHAR像20世纪90年代一样吗? (10)

  1. VARCHAR不存储Unicode字符。
  2. NVARCHAR确实存储Unicode字符。
  3. 今天的应用程序应该始终是Unicode兼容的。
  4. NVARCHAR需要两倍的空间来存储它。
  5. 第4点并不重要,因为存储空间非常便宜。

Ergo:今天设计SQL Server数据库时,应该总是使用NVARCHAR。

这是合理的吗? 有没有人不同意任何前提? 今天有什么理由选择VARCHAR over NVARCHAR吗?


第4点并不重要,因为存储空间非常便宜。

它不仅仅是存储,而是带宽--CPU,内存,备份,恢复,传输。 养护。


你的观点3是无效的。 只为单个国家使用而设计的系统不必担心unicode,一些正在使用的语言/产品根本不支持unicode。 例如, TurboTax只适用于美国(即使加拿大版法文也只是LATIN-1),所以他们不需要也不必担心unicode,可能不支持它(我不知道他们是否做,但即使他们这样做,这只是一个例子)。

“今天的应用程序应该始终是Unicode兼容的。”

可能更有效的表述为:

“今天的应用程序应该始终是Unicode兼容的,如果没有什么特别需要出现以正确处理Unicode,并且以前存在的代码库或任何其他部分的应用程序不需要专门更新以支持它”


您将数据类型与将存储在列中的数据相匹配。 通过类似的说法,你可以说为什么不把所有数据存储在NVARCHAR列中,因为数字和日期可以用数字串表示。

如果要存储在列中的数据的最佳匹配是VARCHAR,则使用它。


我不是这方面的专家。 但是为什么你不能使用UTF-8来获得小空间和unicode的组合呢?


我看到nvarchar列转换为varchar有两个原因:

  1. 应用程序正在使用MSSQL Express Edition ,它具有4GB的数据库大小限制。 如果有很多数据库部署,切换到MSSQL标准版将会非常昂贵,就像在单租户Web应用程序或带嵌入式DBMS的应用程序中一样。 更便宜的SQL2008网络版可以在这里帮助。

  2. nvarchar(4000)是不够的,但你不想要一个ntext列。 所以你转换为varchar(8000)。 但是,在大多数情况下,您可能应该将其转换为nvarchar(max)。


有没有办法让你的数据库服务器使用UTF-8作为编码? 然后,您将获得低存储的好处,主要是ASCII加载,并且可以存储Unicode范围内的任何内容,以便进行扩展。

我会要求你的数据库供应商支持UTF-8作为VARCHAR SQL类型的编码。 我不知道其他数据库服务器是如何做的,但是我知道你至少可以在MySQL和PostgreSQL的VARCHARTEXT字段中使用UTF-8。

尽管如此, 使用UTF-16编码字段的唯一原因是如果您必须与UTF-16输入中断的应用程序进行交互。 这将是大多数遗留应用程序,这些应用程序设计用于处理ASCII或ISO-8815文本编码,这将更好地处理UTF-8。


对于许多不同类型的列,您应该选择VARCHAR over NVARCHAR,并且选择将以每列为基础。

不需要额外开销NVARCHAR的典型列将是:

ID型列:牌照,SSN,患者图表标识符等

代码栏:国际货币代码(USD,UKP等),ISO国家代码(美国,英国等),语言代码(en-us等),会计部门代码等

邮政编码和邮政编码列。


我会说,仍然有正当理由不使用nvarchar。

  • 存储空间非常重要,比如在共享主机上,或者数据库非常庞大。
  • 性能至关重要。
  • 布朗菲尔德开发(即数据库有现有的表使用varchar)。
  • 您正在与另一个只能理解单字节字符和/或varchar的较旧系统集成。

不过新的开发应该可能使用nvarchar esp。 因为64位系统正在成为常态。 此外,公司(甚至小公司)现在更普遍的全球性。


我的倾向是“使用NVARCHAR”作为默认...但@CadeRoux有一个很好的观点:如果你是确定的数据将永远不会持有任何东西,只有ASCII - 像美国车牌 - VARCHAR可能会节省你一点点成本。

对于任何会有名称(人,街道,地方)或自然语言文本(电子邮件,聊天,文章,博客帖子,图片说明)的任何东西,我都会说他的良好声明的另一面是“使用NVARCHAR”。 否则,您的“名字”列将无法正确编码“François”或“José”,而您的文本列将不允许带有“外来”字母标记的文本,或者 - 对于这一点 - 非常常见的美国字符分号“¢”,段落标记“¶”,子弹“•”。 (因为这些都不是ASCII字符 ,没有一个好的,标准的方法把它们放到VARCHAR字段中,相信我:你会伤害自己的。)

在我工作过的任何项目中,我从来没有因使用NVARCHAR而被骂,因为我在“浪费太多公司资金在磁盘空间上”。 如果我不得不重新编写代码或数据库模式(特别是在现场生产系统上),重新安装所花费的成本将比购买小50%的磁盘容易得多。

要真正理解这个问题,你必须理解ASCII,Unicode和Unicode的典型编码(比如UCS-2和UTF-8)。






nvarchar