使用 TSQL，带有 COLLATE 的 CAST() 是不确定的。如何使其具有确定性？解决方法是什么？答案

【问题标题】：Using TSQL, CAST() with COLLATE is non-deterministic. How to make it deterministic? What is the work-around?使用 TSQL，带有 COLLATE 的 CAST() 是不确定的。如何使其具有确定性？解决方法是什么？
【发布时间】：2013-10-02 02:19:13
【问题描述】：

我的功能包括：

SELECT @pString = CAST(@pString AS VARCHAR(255)) COLLATE SQL_Latin1_General_Cp1251_CS_AS

这很有用，例如，去除法语中的重音；例如：

UPPER(CAST('Éléctricité' AS VARCHAR(255)) COLLATE SQL_Latin1_General_Cp1251_CS_AS)

给ELECTRICITE。

但是使用COLLATE 会使函数具有不确定性，因此我不能将其用作列中的计算持久值。

第一季度。是否有另一种（快速且简单）的方法来删除这样的重音，具有确定性功能？

第二季度。（奖励问题）我做这个计算持久列的原因是搜索。例如，用户可以将客户的姓氏输入为“Gagne”或“Gagné”或“GAGNE”或“GAGNÉ”，应用程序将使用持久计算列找到它。有没有更好的方法来做到这一点？

编辑：使用 SQL Server 2012 和 SQL-Azure。

【问题讨论】：

如果有这个级别的问题，你最好在dba.stackexchange.com提问
也许这个链接对你有用，读起来就像在最后一段他正在处理你想要的东西youdidwhatwithtsql.com/comparing-accented-strings-with-tsql/849
Re Q2：考虑使用全文搜索并制作全文目录accent insensitive。
博士：感谢您的链接 - 很棒的 SQL 站点。 Keith：我的理解是你不能在 SQL Azure 中使用全文——最近有变化吗？

标签： tsql sql-server-2012 azure-sql-database non-deterministic

【解决方案1】：

您会发现它实际上是确定性的，只是根据您要整理的角色而具有不同的行为。

检查page for Windows 1251 encoding 以了解可接受字符和不可接受字符的行为。

Here is a collation chart for Cyrillic_General_CI_AI。这是代码页 1251 不区分大小写和不区分重音。这将向您显示此排序规则中所有可接受字符的映射。

至于搜索问题，正如 Keith 所说，我会调查在您要搜索的列上放置全文索引。

【讨论】：

是 SQL 抱怨函数是不确定的。我没有确切消息的副本（我现在已经解决了这个问题），但它会引发错误。所以我不能反驳它不是确定性的。谢谢。
那你是怎么解决这个问题的？

【解决方案2】：

我得到的最佳答案来自Sebastian Sajaroff。我用他的例子来解决这个问题。他建议使用 UNIQUE INDEX 的 VIEW。这给出了解决方案的一个好主意：

create table Test(Id int primary key, Name varchar(20))
create view TestCIAI with schemabinding as
select ID, Name collate SQL_Latin1_General_CP1_CI_AI as NameCIAI from Test 
create unique clustered index ix_Unique on TestCIAI (Id)
create unique nonclustered index ix_DistinctNames on TestCIAI (NameCIAI)
insert into Test values (1, 'Sébastien')
--Insertion 2 will fail because of the unique nonclustered indexed on the view 
--(which is case-insensitive, accent-insensitive)
insert into Test values (2, 'Sebastien')

【讨论】：