nvarchar列可以存储任何Unicode数据。varchar列限制为8位代码页。有些人认为应该使用varchar，因为它占用更少的空间。我认为这不是正确的答案。代码页不兼容性是一个难题，Unicode是解决代码页问题的良方。现在磁盘和内存都很便宜，真的没有理由再浪费时间摆弄代码页了。

所有现代操作系统和开发平台都在内部使用Unicode。通过使用nvarchar而不是varchar，可以避免每次读取或写入数据库时进行编码转换。转换需要时间，而且容易出错。从转换错误中恢复是一个非常重要的问题。

如果您使用的是仅使用ASCII的应用程序，我仍然建议在数据库中使用Unicode。操作系统和数据库排序算法将更好地使用Unicode。Unicode在与其他系统接口时避免了转换问题。你将为未来做准备。您可以始终验证您的数据是否仅限于7位ASCII，无论您要维护的是什么遗留系统，即使您享受完全Unicode存储的一些好处。

nArchar将帮助您存储Unicode字符。如果您想存储本地化的数据，这是一种方法。

nvarchar将数据存储为Unicode，因此，如果要在数据列中存储多语言数据（多种语言），则需要N变量。

我会说，这取决于情况。

如果您开发一个桌面应用程序，其中操作系统以Unicode（与所有当前的Windows系统一样）工作，并且语言本身支持Unicode（默认字符串为Unicode，如Java或C#），那么使用nvarchar。

如果您开发了一个web应用程序，其中字符串以UTF-8形式出现，语言为PHP，而PHP本身仍然不支持Unicode（在5.x版本中），那么varchar可能是一个更好的选择。

与varchar相比，nvarchar使用起来是安全的，因为nvarchar也允许unicode字符，所以我们的代码不会出错（类型不匹配）。当我们在SQL Server查询中使用where条件时，如果我们使用的是=运算符，它会多次抛出错误。可能的原因是我们的映射列将在varchar中定义。如果我们在nvarchar中定义它，这个问题就不会发生。尽管如此，我们还是坚持varchar并避免这个问题，我们最好使用LIKE关键字而不是=。

varchar：可变长度、非Unicode字符数据。数据库排序规则确定使用哪个代码页存储数据。

nvarchar：可变长度Unicode字符数据。取决于用于比较的数据库排序规则。

掌握了这些知识后，使用与输入数据匹配的数据（ASCII与Unicode）。