遵循Sql Server VARCHAR和NVARCHAR数据类型之间的差异。在这里，你可以看到一个非常描述性的方式。

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

我看了一下答案，许多人似乎建议使用nvarchar而不是varchar，因为空间不再是问题，所以启用Unicode以获得很少的额外存储不会有什么害处。嗯，当你想在列上应用索引时，这并不总是正确的。SQL Server对可以索引的字段的大小限制为900字节。因此，如果您有一个varchar（900），您仍然可以对其进行索引，但不能对varchar（901）进行索引。使用nvarchar，字符数减半，因此可以索引到nvarchar（450）。因此，如果您确信不需要nvarchar，我不建议使用它。

一般来说，在数据库中，我建议您坚持所需的大小，因为您可以随时扩展。例如，一位同事曾经认为，对列使用nvarchar（max）没有害处，因为我们在存储方面完全没有问题。后来，当我们试图对此列应用索引时，SQL Server拒绝了这一点。然而，如果他甚至从varchar（5）开始，我们可以简单地将其扩展到我们需要的内容，而不会出现这样的问题，这将要求我们制定一个字段迁移计划来解决这个问题。

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

虽然NVARCHAR存储Unicode，但您应该考虑借助于排序，您也可以使用VARCHAR并保存本地语言的数据。

想象一下下面的场景。

DB的排序规则是波斯语，您可以在VARCHAR（10）数据类型中保存一个类似“علی”（阿里的波斯语书写）的值。没有问题，DBMS只使用三个字节来存储它。

但是，如果要将数据传输到另一个数据库并查看正确的结果，则目标数据库必须与目标数据库具有相同的排序规则，在本例中为波斯语。

如果目标排序规则不同，则会在目标数据库中看到一些问号（？）。

最后，请记住，如果您使用的是用于本地语言的大型数据库，我建议您使用位置，而不是使用太多空间。

我相信设计会有所不同。这取决于你工作的环境。

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

我不得不在这里说（我意识到我可能会打开自己的心扉！），但NVARCHAR确实比VARCHAR更有用（注意更多！）的唯一时间是，所有从属系统上的所有排序规则和数据库本身都是相同的。。。？如果没有，那么无论如何都必须进行排序规则转换，因此VARCHAR和NVARCHAR一样可行。

除此之外，一些数据库系统，如SQL Server（2012年之前）的页面大小约为8K。因此，如果您要存储未保存在TEXT或NTEXT字段中的可搜索数据，那么VARCHAR提供了8k的完整空间，而NVARCHAR仅提供4k（双倍字节，双倍空间）。

总之，我想，两者的使用取决于：

项目或上下文基础设施数据库系统