sql-server – 选择可以区分Sql Server中nvarchar列的’ss’和’

不过,我不知道这是否是一般的做法.另外我不知道除了以下内容之外的含义：

>更改排序顺序：因为我从来没有对这一列的数据进行排序,对我来说可能不是一个问题.但是,如果你另有想法,请让我知道.
>改变不区分大小写的敏感性：由于我的应用程序总是提供小写的文本,我认为这种改变对我来说也不是一个问题.但是,请让我知道.

我很好奇这个变化的其他主要影响,如果有的话.

此外,我还想知道以下哪一个最适合这种情况：

SQL_Latin1_General_CP437_BIN

Description: Latin1-General,binary sort for Unicode Data,SQL Server Sort Order 30 on Code Page 437 for non-Unicode Data

---

SQL_Latin1_General_CP437_BIN2

Description: Latin1-General,binary code point comparison sort for Unicode Data,SQL Server Sort Order 30 on Code Page 437 for non-Unicode Data

---

SQL_Latin1_General_CP850_BIN

Description: Latin1-General,SQL Server Sort Order 40 on Code Page 850 for non-Unicode Data

---

SQL_Latin1_General_CP850_BIN2

Description: Latin1-General,SQL Server Sort Order 40 on Code Page 850 for non-Unicode Data

如果您认为还有其他排序规则更适合这种情况,请提及这些.

19.03.2017更新：
对任何人来说这个问题：

>必须检查来自@srutzky和@SqlZim的答案以及相关的引用资源.在这种情况下你不想匆匆忙忙.
>随着更改排序规则不是微不足道：P,保留表数据的备份可能会派上用场.
>还要检查列的依赖关系,如索引和约束;你可能需要删除并创建它们,就像我的情况.

玩的开心 ：)

解决方法

>从SQL Server 2000开始,SQL_ Collat??ions已被弃用(是的,2000年).如果你可以避免使用它们,你应该(但是并不意味着如果没有紧迫的需要,就改变一堆事情！).

SQL_ Collat??ions的问题实际上仅与VARCHAR(即非Unicode)数据相关,因为NVARCHAR(即Unicode)数据使用来自操作系统的规则.但是,对于VARCHAR数据的排序和比较的规则,不幸的是使用简单的映射,并不包括更复杂的语言规则.这就是为什么ss和?在使用相同的SQL_Latin1_General_CP1_CI_AS排序规则存储为VARCHAR时不等同.这些不推荐的排序方式在单词中间使用时也不能给予较低的重音.非SQL_ Collat??ions(即Windows Collat??ions)对VARCHAR和NVARCHAR使用相同的规则,因此VARCHAR处理更加强大,与NVARCHAR更一致.
>从SQL Server 2005开始,_BIN Collat??ions已经被弃用了.如果你可以避免使用它们,那么你应该(但是并不意味着如果没有必要的话)改变一堆东西！

_BIN Collat??ions的问题相当微妙,因为它只影响排序. _BIN和_BIN2之间的比较是相同的,因为它们在字节级别进行比较(因此没有语言规则).但是,由于SQL Server(和Windows / PC)是Little Endian,实体按照反向字节顺序存储.当处理双字节“字符”时,这显然是NVARCHAR数据：UTF-16 Little Endian.这意味着Unicode码点U1216在大端系统上具有0x1216的十六进制/二进制表示形式,但在小端系统上存储为0x1612.要完整的圆圈,以便这个最后一点的重要性(希望)变得明显：_BIN Collat??ions将逐字节(第一个字符之后)进行比较,因此将U1216视为0x16,然后将0x12视为0x12,而_BIN2 Collat??ions将通过代码点比较代码点,因此将U1216视为0x12,然后将0x16.
>这个特定的列是NVARCHAR(使用SQL_Latin1_General_CP1_CI_AS的VARCHAR列不等于ss和?),因此仅仅这个列,SQL_Latin1_General_CP437_BIN2和SQL_Latin1_General_CP850_BIN2之间没有区别,因为Unicode是一个单一的全包字符集.
>对于VARCHAR数据,由于它们是不同的代码页(437和850),因此这两者都不同于现在使用的代码页(CP1 ==代码页1252).
>虽然使用二进制排序通常是过度的,但在这种情况下,可能需要考虑到只有一个区域设置/文化不等于?与ss：Hungarian.使用匈牙利排序规则可能会有一些您不想要的语言规则(或至少不会期望),所以二进制排序规则似乎是更好的选择(只是你们中没有任何一个要求:-) .请记住,通过使用二进制排序规则,不仅您放弃了所有语言规则,而且您也失去了等同于A(Latin Capital Letter A U+0041)和A(Fullwidth Latin Capital Letter A U+FF21)相同字符的不同版本的能力.

使用以下查询来查看排序是非二进制的,不等于这些字符：

DECLARE @SQL NVARCHAR(MAX) = N'DECLARE @Counter INT = 1;';

SELECT @SQL += REPLACE(N'
  IF(N''?'' COLLATE {Name} = N''ss'' COLLATE {Name})
  BEGIN
    RAISERROR(N''%4d.  {Name}'',10,1,@Counter) WITH NOWAIT;
    SET @Counter += 1;
  END;
',N'{Name}',col.[name]) + NCHAR(13) + NCHAR(10)
FROM   sys.fn_helpcollations() col
WHERE  col.[name] NOT LIKE N'SQL[_]%'
AND    col.[name] NOT LIKE N'%[_]BIN%'
ORDER BY col.[name]

--PRINT @SQL;
EXEC (@SQL);

所以：

>如果要使用二进制排序规则,请使用类似Latin1_General_100_BIN2的内容.
>您不需要更改整个数据库及其所有表的排序规则.这是很多工作,唯一的“内置”机制是无证的(即不支持).
>如果要更改数据库的默认排序规则,这会影响数据库作用域项目(如表,列,索引,函数,存储过程等)的名称解析.意义：您需要退出100％数据库,以及触摸此数据库的所有SQL Server代理作业等.
>如果使用此列的大多数/所有查询都需要?,将ss视为不同的,请继续更改列以使用Latin1_General_100_BIN2.这可能需要删除以下依赖对象,然后在ALTER TABLE之后重新创建：

>索引
>唯一约束
>外键限制

提示：确保检查列的当前NULL / NOT NULL设置,并在ALTER TABLE … ALTER COLUMN …语句中指定它,以便不会更改.>如果只有一些查询需要这个不同的行为,那么在每个条件的基础上(例如WHERE选项卡),只用COLLATE子句覆盖这些比较操作.[ThisColumn] LIKE N’％ss％’COLLATE Latin1_General_100_BIN2). COLLATE关键字只应在运算符的一侧(因为排序规则优先级将应用于另一方)需要.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!