我正在学校使用SQL Server 2005为小型Web应用程序开发数据库。
我看到一些关于varchar和vs nvarchar的思想流派：

• 除非我们处理许多国际化的数据，否则请使用" varchar"，然后使用" nvarchar"。
• 只需对所有内容使用nvarchar。

我开始看到视图2的优点。我知道nvarchar确实占用了两倍的空间，但这并不一定是什么大问题，因为这只会存储数百名学生的数据。在我看来，最简单的方法就是不用担心它，只允许所有内容都使用nvarchar。还是我想念的东西？

解决方案

回答

始终使用nvarchar。

对于大多数应用程序，我们可能永远不需要双字节字符。但是，如果我们需要支持双字节语言，并且数据库模式中仅支持单字节，那么回头修改整个应用程序确实非常昂贵。

将一个应用程序从varchar迁移到nvarchar的成本将比我们在大多数应用程序中使用的额外磁盘空间少得多。

回答

由于应用程序很小，因此与使用varchar相比，使用nvarchar基本上不会增加​​任何成本，并且，如果需要存储unicode数据，则可以避免麻烦。

回答

磁盘空间不是问题……但是内存和性能将成为问题。
页面读取翻倍，索引大小翻倍，奇怪的LIKE和=恒定行为等

我们需要存储中文等脚本吗？是还是不是...

摘自MS BOL" Unicode的存储和性能影响"

编辑：

最近的SO问题强调了nvarchar性能可能有多差...

在nvarchar字符串中搜索时，SQL Server使用高CPU

回答

始终如一！将VARCHAR联接到NVARCHAR会对性能产生重大影响。

回答

nvarchar将在内存，存储，工作集和索引编制上有大量开销，因此，如果规范指示确实不需要，则不要打扰。

我不会有严格的"总是nvarchar"规则，因为在许多情况下，尤其是来自ASCII / EBCDIC的ETL或者通常是键和外键的标识符和代码列，这可能是一个完全的浪费。

另一方面，有很多列的情况，我一定会提早问这个问题，如果我没有立即得到一个快速而准确的答案，我将列设为nvarchar。

回答

我经常在工作中处理这个问题：

• 清单和价格的FTP提要-varchar正常工作时，项目描述和其他文本在nvarchar中。将它们转换为varchar可以将文件大小减少近一半，并且确实有助于上传。
• 在有人在商品说明中添加特殊字符之前，上述方案可以正常工作(也许是商标，不记得了)

我还是不会每次都使用varchar来使用nvarchar。如果对特殊字符有任何疑问或者潜力，我可以使用nvarchar。我发现我在100％控制填充字段时主要使用varchar。

回答

对于应用程序，nvarchar很好，因为数据库大小很小。说"总是使用nvarchar"是一个过分的简化。如果我们不需要存储汉字或者其他疯狂人物之类的东西，请使用VARCHAR，它将减少很多空间。我当前工作的前任在不需要时使用NVARCHAR设计了一些东西。我们最近将其切换为VARCHAR，仅在该表上保存了15 GB(已被高度写入)。此外，如果我们在该表上有一个索引，并且想要包括该列或者创建一个复合索引，则只需增加索引文件的大​​小即可。

请慎重考虑决定；在SQL开发和数据定义中，似乎很少有"默认答案"(当然，除了不惜一切代价避免使用游标)。

回答

在过去的几年中，我们所有的项目都使用NVARCHAR进行所有操作，因为所有这些项目都是多语言的。从外部源(例如ASCII文件等)导入的数据在插入数据库之前先进行上转换为Unicode。

我还没有遇到较大的索引等与性能相关的问题。索引确实使用了更多的内存，但是内存很便宜。

无论我们是使用存储过程还是动态构造SQL，请确保所有字符串常量都以N为前缀(例如SET @foo = N'Hello world。';)，因此该常量也是Unicode。这样可以避免在运行时进行任何字符串类型转换。

YMMV。

回答

为什么在所有讨论中都没有提到UTF-8？能够存储完整的unicode字符范围并不意味着必须始终分配每个字符两个字节(或者使用UNICODE术语的"代码点")。所有ASCII均为UTF-8. SQL Server是否检查VARCHAR()字段以确保文本是严格的ASCII码(即最高字节位为零)？我希望不会。

如果要存储unicode并希望与旧的纯ASCII应用程序兼容，我认为使用VARCHAR()和UTF-8将是神奇的子弹：它仅在需要时使用更多空间。

对于那些不熟悉UTF-8的人，我可能建议我们入门。