Ergo：今天设计SQL Server数据库时，应始终使用NVARCHAR。
这听起来有道理吗？有没有人不同意任何前提？ 今天有没有理由在NVARCHAR上选择VARCHAR？
答案 0 :(得分：49)
您将数据类型与将存储在列中的数据相匹配。通过类似的参数，您可以说为什么不将所有数据存储在NVARCHAR列中，因为数字和日期可以表示为数字字符串。
如果要存储在列中的数据的最佳匹配是VARCHAR，则使用它。
答案 1 :(得分：40)
第4点无关紧要，因为存储空间非常便宜。
它不仅仅是存储，而是带宽 - CPU，内存，备份，恢复，传输。保存。
答案 2 :(得分：27)
我会说仍然有正当理由不使用nvarchar。
然而，新开发应该使用nvarchar esp。因为64位系统正在成为常态。此外，公司（即使是小公司）现在更普遍是全球性的。
答案 3 :(得分：18)
对于许多不同类型的列，您应该选择VARCHAR而不是NVARCHAR，并且选择将按列进行选择。
不需要NVARCHAR额外开销的典型列将是：
ID类型列：车牌，SSN，患者图表标识符等。
代码栏：国际货币代码（USD，UKP等），ISO国家代码（美国，英国等），语言代码（en-us等），会计分部代码等
邮政编码和邮政编码列。
答案 4 :(得分：11)
我认为nvarchars的比较比varchars更昂贵，因此它非常有效，甚至在你真正不需要unicode功能的地方也是首选，也就是说，对于一些内部ID。
存储成本仍然确实重要。如果你有数十亿行，那么这些“小”差异会变得非常快。
答案 5 :(得分：5)
正如其他人所指出的那样，不仅仅是存储成本。
列的长度将影响每页的行数。每页的行数减少意味着您的缓存中可以容纳更少的行，这会降低性能。我假设在MSSQL中，索引的NVARCHAR列将占用索引中更多的空间。这意味着每个块的索引条目越少，因此索引中的块越多，因此在扫描（或搜索）索引时会有更多的搜索，这也会降低索引访问的速度。
所以它在每一个方面都失去了你的表现。如果你真的不关心（或者可以衡量表现并且对它感到满意），那就没关系了。但是，如果你真的需要存储unicode字符，当然要使用NVARCHAR。
我可能认为在整个数据库中使用NVARCHAR所获得的可维护性超过任何性能成本。
答案 6 :(得分：5)
这些问题总是有相同的答案：取决于。你应该盲目追随没有神奇的规则。即使在现代编程语言中使用GOTO也是合理的：Is it ever advantageous to use 'goto' in a language that supports loops and functions? If so, why?
所以答案是：用你的头脑思考特定的情况。在这个特定的实例中，请记住，如果结果证明您的需求发生了变化，您始终可以从数据库中的varchar转换为nvarchar。
答案 7 :(得分：4)
我已经看到nvarchar列转换为varchar有两个原因：
应用程序正在使用MSSQL Express 版本，其数据库大小为4GB 限制。切换到MSSQL标准 如果版本太贵了 有许多数据库部署， 就像单租户webapps一样 或嵌入式DBMS的应用程序。 更便宜的SQL2008网络版 可以帮到这里。
nvarchar（4000）还不够但是你 不想要一个ntext列。那么你 转换为varchar（8000）。然而， 在大多数情况下，您可能应该转换为nvarchar（max）。
答案 8 :(得分：3)
您的观点3无效。仅为单个国家/地区使用而设计的系统不必担心unicode，并且某些使用的语言/产品根本不支持unicode或仅支持部分unicode。例如，TurboTax仅适用于美国（即使加法语版本仍然只有LATIN-1），因此他们不需要或不必担心unicode并且可能不支持它（我不知道他们是否这样做，但即使他们这样做，也只是一个例子。
“今天的应用程序应始终与Unicode兼容。”
可能更有效表达为：
“今天的应用程序应始终与Unicode兼容，如果没有特别需要正确处理Unicode，并且以前存在的代码库或应用程序的任何其他部分不需要专门更新以支持它”
答案 9 :(得分：2)
存储比以往任何时候都要便宜，但如果你能在给定的硬盘上存储两倍的数据，这仍然很有吸引力，不是吗？
还有用于缓存的RAM和固态驱动器，它们都比硬盘驱动器贵得多。当你有数百万行时，使用更紧凑的数据格式是有益的。
答案 10 :(得分：2)
您的数据库服务器是否有办法使用UTF-8作为编码？然后，您可以获得大部分ASCII加载的低存储优势，并能够存储Unicode范围内的任何内容，以便可以进行扩展。
我会要求您的数据库供应商支持UTF-8作为VARCHAR SQL类型的编码。我不知道其他数据库服务器是如何做到这一点的，但我知道你可以在VARCHAR和TEXT字段中使用UTF-8，至少在MySQL和PostgreSQL中。
尽管如此，不使用UTF-16编码字段的唯一原因是，如果您必须与将在UTF-16输入中断的应用程序进行交互。这将是大多数旨在处理ASCII或ISO-8815文本编码的遗留应用程序，这样可以更好地处理UTF-8。
答案 11 :(得分：2)
我的倾向是“使用NVARCHAR”作为默认值...但@CadeRoux有一个好点：如果你确定数据永远不会包含任何东西而不是ASCII - 就像美国牌照一样 - VARCHAR可能会省你一点点成本。
我会说他的良好声明的另一面是“DO use NVARCHAR”用于任何有名字（人物，街道，地方）或自然语言文本（电子邮件，聊天，文章，博客帖子，照片）字幕）。否则，您的“firstname”列将无法正确编码“François”或“José”，并且您的文本列将不允许带有“外国”diacritcal标记的文本，或者 - 就此而言 - 非常常见的美国字符，如分号“¢”，段号“¶”，子弹“•”。 （因为这些都不是 ASCII字符，并且没有好的标准方法将它们放入VARCHAR字段。相信我：你会伤到自己。）
在我参与的任何项目中，我从未因使用NVARCHAR而被责骂，因为我“在磁盘空间上浪费了太多的公司资金”。如果我不得不重做代码或数据库架构（特别是在现场生产系统上），重新装配所花费的成本将比购买小50％的磁盘的“节省”更加轻松。
要真正理解这个问题，你必须要了解ASCII，Unicode和Unicode的典型编码（如UCS-2和UTF-8）。
答案 12 :(得分：1)
我不是这方面的专家。但是你有什么理由不能使用UTF-8来获得小空间和unicode的组合吗？
答案 13 :(得分：1)
我见过一些数据库，其中索引（索引？...不同的争论）比数据大。如果一个人可以在索引中获得一半的存储需求（varchar），那么假定等于给定页面的命中密度的两倍，并且更有效的填充因子导致更快的数据检索/写入/锁定＆amp;存储要求较少（已经提到）。