我正在我的学校使用SQL Server 2005为一个小型web应用程序开发数据库。 我在varchar vs nvarchar的问题上看到了几个学派的思想:
使用varchar,除非你要处理大量国际化的数据,否则就使用nvarchar。 只要用nvarchar就可以了。
我开始看到观点二的优点了。我知道nvarchar占用了两倍的空间,但这并不一定是一个大问题,因为它只存储几百个学生的数据。对我来说,不担心它,允许所有东西都使用nvarchar似乎是最简单的方法。还是我遗漏了什么?
我正在我的学校使用SQL Server 2005为一个小型web应用程序开发数据库。 我在varchar vs nvarchar的问题上看到了几个学派的思想:
使用varchar,除非你要处理大量国际化的数据,否则就使用nvarchar。 只要用nvarchar就可以了。
我开始看到观点二的优点了。我知道nvarchar占用了两倍的空间,但这并不一定是一个大问题,因为它只存储几百个学生的数据。对我来说,不担心它,允许所有东西都使用nvarchar似乎是最简单的方法。还是我遗漏了什么?
当前回答
在某些特殊情况下,您会有意限制数据类型,以确保它不包含某个特定集合中的字符。例如,我有一个场景,我需要在数据库中存储域名。域名的国际化在当时是不可靠的,所以最好限制在基础水平上的输入,并有助于避免任何潜在的问题。
其他回答
是一致的!加入一个VARCHAR到NVARCHAR有一个很大的性能打击。
如果您使用NVARCHAR只是因为系统存储过程需要它,最常见的情况是莫名其妙的sp_executesql,并且您的动态SQL非常长,那么从性能角度来看,您最好在VARCHAR中进行所有字符串操作(连接、替换等),然后将最终结果转换为NVARCHAR并将其输入到proc参数中。所以,不要总是使用NVARCHAR!
我在工作中经常遇到这样的问题:
库存和定价的FTP提要-当varchar工作正常时,项目描述和其他文本是在nvarchar中。将这些文件转换为varchar可以将文件大小减少近一半,并且对上传非常有帮助。 上面的场景工作得很好,直到有人在商品描述中添加了一个特殊字符(可能是商标,不记得了)
我还是不会每次都用varchar。如果有任何疑问或特殊字符的潜力,我使用nvarchar。我发现,当我100%控制填充字段的内容时,我主要使用varchar。
磁盘空间不是问题…但是记忆和性能会。 双倍的页面阅读量,双倍的索引大小,奇怪的LIKE和=恒定的行为等等
你需要存储中文等脚本吗?是或不是…
来自MS BOL的《Unicode的存储和性能影响》
编辑:
最近的SO问题强调了nvarchar性能有多差…
SQL Server在搜索nvarchar字符串时使用高CPU
为什么在所有这些讨论中,没有提到UTF-8?能够存储完整的unicode字符跨度并不意味着必须总是为每个字符分配两个字节(或使用unicode术语的“码位”)。所有的ASCII都是UTF-8。SQL Server检查VARCHAR()字段,文本是严格的ASCII(即顶部字节位零)?我希望不是。
如果您希望存储unicode并希望与旧的仅使用ascii的应用程序兼容,我认为使用VARCHAR()和UTF-8将是神奇的子弹:它只在需要时使用更多的空间。
对于那些不熟悉UTF-8的人,我可以推荐一个入门。