我们有一个用C#编写的应用程序,使用.NET Framework 3.0或3.5或类似的东西。作为存储,我们使用SQL Server,我们使用Linq 2 SQL与它进行通信。
目前,数据库中的大多数(如果不是全部)文本列都设置为varchar类型(当然,长度不同)。
但我开始思考......根据MSDN“字符串类型表示零个或多个Unicode字符的序列。”这是否意味着我们应该真正将这些列更改为nvarchar以便正确存储?或者这是如何工作的?他们最初将它们设置为varchar的原因是因为nvarchar需要两倍的空间(如果我已经正确理解的话)。到目前为止,我已经看到它与varchar一起使用,但是我们还没有对异常的外来字符进行过多的测试......
有人可以对此有所了解吗?
答案 0 :(得分:10)
除非您的文本保证在数据库的代码页中可以表示(或者您明确指定了排序规则),否则我将使用nvarchar。
在某些情况下,您可以保证内容将是ASCII,在这种情况下您确实可以使用varchar - 但我不知道它的好处与制作的麻烦相比有多重要绝对确保不仅内容为ASCII,而且从不除了ASCII之外(或在特定代码页中)
。答案 1 :(得分:9)
从.net方面来看有很多观点。这是数据库方面的一个想法:
varchar是nvarchar大小的一半。虽然这对于许多目的来说并不重要,但它对索引非常重要。索引宽度的一半是两倍快。这是因为可以在数据页(数据库IO的单元)上存储两倍的值。
您(来自应用程序)有某些字符串控制构建并希望用于访问重要记录。字母数字标识符(例如客户编号)属于此类别。由于您可以控制构造,因此可以强制这些构造安全地进行varchar(并且经常进行)。为什么不能为你已经在做的这项努力获得半长双倍快速指数的好处呢?
答案 2 :(得分:3)
是的,nvarchar
将字符存储为unicode,就像.NET字符串一样。如果您需要存储包含不同语言字符的字符串,则应该使用nvarchar
。
如果您只有一种语言的字符,则可以使用varchar
选择其他选项,并选择该语言的特定排序规则(这样可以节省空间,但会让生活更加复杂)。
答案 3 :(得分:1)
正如其他人所说,你的应用程序是否会存储2字节Unicode(UTF-16/32)?如果没有那么varchar对于普通的ascii就好了(甚至可能是Window默认的UTF8,不确定)。 .NET字符串实际上是作为UTF16实现的。
除非您在数据库中持有大量文本并且磁盘空间不足,否则差异很小,因此您可以坚持使用NVarchar。
答案 4 :(得分:1)
如果您使用的是SQL2005,那么一定要使用nvarchar。如果您正在使用SQL2000,那么请注意8000字节的总行大小限制 - 您将更快地使用nvarchar,因为它们占用了两倍的空间。
答案 5 :(得分:0)
是的,您确实应该使用NVARCHAR,否则您可能会因编码问题而丢失字符。
我认为,到目前为止,您的帖子的有效部分是 。
尝试一些例子,使用charmap中字符中心下方的一些字符,比如阿拉伯字符,看看它们是如何存储的。
答案 6 :(得分:0)
T-SQL中的NVARCHAR(X)转换为“UTF-16编码”:每个X字符都是16位宽。如果您要存储人类可读的文本,那么最好使用NVARCHAR进行文本存储。 VARCHAR(X)意味着字符的8位存储。这意味着必须在C#应用程序(在string
类型内部使用UTF-16)和数据库之间进行转码。
在存储人类可读的字符串时,请保持自己的一些悲伤并使用Unicode。