我犹豫在这里添加另一个答案，因为已经有很多答案了，但是需要提出一些尚未提出或没有明确提出的观点。
第一：待办事项不经常使用NVARCHAR。这是非常危险的，而且往往是昂贵的态度/方法。最好不要说“ 从不使用游标”，因为它们有时是解决特定问题的最有效方法，并且进行WHILE循环的常见解决方案几乎总是比正确完成游标要慢。
建议您“始终做最适合情况的”时，才应使用“始终”一词。当然，这通常很难确定，尤其是在试图平衡开发时间的短期收益时（经理：“我们需要此功能-您直到一周前才知道的功能！”）长期维护成本（最初向团队施加压力，要求其在3周的冲刺中完成3个月的项目的经理：“我们为什么会遇到这些性能问题？我们怎么可能做没有灵活性的X？我们负担不起一两个冲刺即可解决此问题。我们一周之内可以完成什么工作，以便我们可以重新处理优先事项？我们绝对需要在设计上花费更多的时间，以免这种情况不断发生！”）
第二： @gbn的答案涉及一些非常重要的要点，当路径不是100％清晰时，在做出某些数据建模决策时要考虑。但是，还有更多需要考虑的问题：
- 事务日志文件的大小
- 复制所需的时间（如果使用复制）
- ETL花费的时间（如果是ETLing）
- 将日志传送到远程系统并还原所需的时间（如果使用日志传送）
- 备份大小
- 完成备份所需的时间
- 进行恢复所花费的时间（这一天可能很重要；-)
- tempdb所需的大小
- 触发器的性能（用于存储在tempdb中的已插入和已删除表）
- 行版本控制的性能（如果使用SNAPSHOT ISOLATION，则因为版本存储在tempdb中）
- 当首席财务官说他们去年在SAN上花费了100万美元时，就可以获取新的磁盘空间，因此他们不会再授权25万美元用于额外的存储
- 进行INSERT和UPDATE操作所需的时间
- 维护索引所需的时间
- 等等等等
浪费空间对整个系统具有巨大的级联效应。我写了一篇文章，详细介绍了该主题：磁盘便宜！奥利？（需要免费注册；抱歉，我无法控制该政策）。
第三：虽然有些答案错误地侧重于“这是一个小应用程序”方面，而有些答案正确地建议“使用适当的内容”，但这些答案都没有为OP提供真正的指导。问题中提到的重要细节这是他们学校的网页。大！因此，我们建议：
- 对于学生和/或教师的名字字段应该大概是
NVARCHAR因为，随着时间的推移，它只是变得更可能是来自其他文化的名称将显示在那些地方了。
- 但是街道地址和城市名称呢？该应用程序的用途并未说明（这将有所帮助），但假定地址记录（如果有）仅与特定地理区域（即，一种语言/文化）有关，然后
VARCHAR与适当的代码页一起使用（由字段的排序规则确定）。
- 如果存储州和/或国家/地区的ISO代码（无需存储
INT/，TINYINT因为ISO代码是固定长度的，易于阅读，而且是标准的:），请使用CHAR(2)两个字母代码，CHAR(3)如果使用3个字母代码。并考虑使用二进制排序规则，例如Latin1_General_100_BIN2。
- 如果存储邮政编码（即邮政编码），请使用，
VARCHAR因为这是国际标准，切勿使用AZ以外的任何字母。是的，VARCHAR即使仅存储美国邮政编码而不是INT ，也仍要使用，因为邮政编码不是数字，它们是字符串，并且其中一些带有前导“ 0”。并考虑使用二进制排序规则，例如Latin1_General_100_BIN2。
- 如果存储电子邮件地址和/或URL，请使用，
NVARCHAR因为这两个现在都可以包含Unicode字符。
- 等等....
第四：现在，您的NVARCHAR数据占用的空间是正常存储的数据VARCHAR（“正常存储” =不会变成“？”）所需空间的两倍，并且就像魔术一样，应用程序确实在增长现在至少在这些字段之一中有数百万条记录，其中大多数行是标准ASCII，但有些行包含Unicode字符，因此必须保留NVARCHAR，请考虑以下几点：
如果您使用的是SQL Server 2008-2016 RTM 且在Enterprise Edition上，或者使用SQL Server 2016 SP1（使Data Compression在所有版本中均可用）或更高版本，则可以启用Data Compression。数据压缩可以（但不会“总是”）压缩NCHARand NVARCHAR字段中的Unicode数据。决定因素是：
NCHAR(1 - 4000)并NVARCHAR(1 - 4000)使用Unicode的标准压缩方案，但只能在SQL Server 2008 R2中开始，并且仅对行数据有效，而不能用于过流！这似乎比常规的ROW / PAGE压缩算法要好。NVARCHAR(MAX)并且XML（而且我猜也是VARBINARY(MAX)，TEXT和NTEXT）行内（不在LOB或OVERFLOW页中的行外）数据至少可以进行PAGE压缩，而不能进行 ROW压缩。当然，PAGE压缩取决于行内值的大小：我使用VARCHAR（MAX）进行了测试，发现不会压缩6000个字符/字节的行，但是会压缩4000个字符/字节的行。- 任何行外数据，LOB或OVERLOW =无需压缩！
如果使用SQL Server 2005或2008-2016 RTM 而不在Enterprise Edition上使用，则可以有两个字段：一个VARCHAR和一个NVARCHAR。例如，假设您存储的URL大多都是基本ASCII字符（值0-127），因此适合VARCHAR，但有时具有Unicode字符。您的架构可以包括以下3个字段：
...
URLa VARCHAR(2048) NULL,
URLu NVARCHAR(2048) NULL,
URL AS (ISNULL(CONVERT(NVARCHAR([URLa])), [URLu])),
CONSTRAINT [CK_TableName_OneUrlMax] CHECK (
([URLa] IS NOT NULL OR [URLu] IS NOT NULL)
AND ([URLa] IS NULL OR [URLu] IS NULL))
);
在此模型中，您只能从[URL]计算列中进行选择。对于插入和更新，您可以通过查看转换是否会改变输入值来确定要使用哪个字段，该字段必须是以下NVARCHAR类型：
INSERT INTO TableName (..., URLa, URLu)
VALUES (...,
IIF (CONVERT(VARCHAR(2048), @URL) = @URL, @URL, NULL),
IIF (CONVERT(VARCHAR(2048), @URL) <> @URL, NULL, @URL)
);
您可以将传入值GZIP VARBINARY(MAX)压缩，然后在解压缩时解压缩：
- 对于SQL Server 2005-2014：可以使用SQLCLR。SQL＃（我编写的SQLCLR库）在免费版本中随附Util_GZip和Util_GUnzip
- 对于SQL Server 2016及更高版本：您可以使用内置
COMPRESS和DECOMPRESS函数，它们也是GZip。
如果使用SQL Server 2017或更高版本，则可以考虑使该表成为集群列存储索引。
虽然这不是一个可行的选择，但SQL Server 2019在VARCHAR/ CHAR数据类型中引入了对UTF-8的本机支持。当前有太多的错误需要使用，但是，如果它们已修复，则在某些情况下是一种选择。请参阅我的文章《SQL Server 2019中的本机UTF-8支持：救星还是假先知？》，以详细了解此新功能。