Sql 使用不同长度的传入号码（带或不带前缀）查找电话号码_Sql_Select_Case_Phone Number_Case When

Sql 使用不同长度的传入号码（带或不带前缀）查找电话号码

sql select

Sql 使用不同长度的传入号码（带或不带前缀）查找电话号码,sql,select,case,phone-number,case-when,Sql,Select,Case,Phone Number,Case When,系统： -呼叫中心电话系统：来电伴有来源号码，又名来电者ID，又名ANI -SQL Server 2005-数据仓库，在表[CustDataByANI]中存储客户电话号码[cANI]、客户名称、位置等 -存储过程-呼叫中心软件将呼叫者ID（也称ANI）作为参数传递给SP，SP使用它在CustDataByANI表上执行当前简单的SELECT语句…其中[cANI]=@ANI。如果查询找到@ANI和“查找表”中包含的686K cANI值之一之间的精确匹配，那么这将非常有效。这种情况只发生在大约12%

系统： -呼叫中心电话系统：来电伴有来源号码，又名来电者ID，又名ANI -SQL Server 2005-数据仓库，在表[CustDataByANI]中存储客户电话号码[cANI]、客户名称、位置等 -存储过程-呼叫中心软件将呼叫者ID（也称ANI）作为参数传递给SP，SP使用它在CustDataByANI表上执行当前简单的SELECT语句…其中[cANI]=@ANI。如果查询找到@ANI和“查找表”中包含的686K cANI值之一之间的精确匹配，那么这将非常有效。这种情况只发生在大约12%的时间里。目标：增加成功的可能/可能匹配的数量重要提示：我们使用的是全局数据集，无法强制执行有关参数@ANI中的值或[cANI]中的值长度的规则。案例1：电话系统传输源号码“9876543210”，该号码用作参数@ANI 该确切数字存在于CustDataByANI表记录55555的[cANI]列中 Select语句返回与记录55555相关的许多其他列的值超级简单：[cANI]=@ANI成功的地方。案例2： @ANI='19876543210'与上面相同，但带有前导'1' 在CustDataByANI.cANI中未找到精确匹配项在[cANI]中最接近的匹配是'9876543210'，仍然保持记录55555 即使是孩子也会认识到，与案例1的唯一区别在于参数@ANI中存在一个1位数的“前缀”——可能是一个长途“标签”或国家代码。这样的前缀长度可能是1、2甚至3位……我们无法预测。我们不想考虑前缀大于3，但在这种情况下，确实希望返回记录55555中的值，如在情况1中。案例3：案例2的“反面” @ANI='9876543210' 在CustDataByANI.cANI中未找到精确匹配项 [cANI]中最接近的匹配是'19876543210'记录55555现在有一个'1'前缀再一次，我们假设这两个概念实质上是等价的。在这种情况下，[cANI]值由于前缀而包含较长的序列，其长度可能为1、2甚至3位……我们无法预测。我们不想考虑前缀大于3，但在这种情况下，确实希望返回记录55555中的值，如在情况1中。同样，由于@ANI和[cANI]的每个值的长度可能会发生变化，而且我几乎完全没有SQL编程，因此我无法为存储过程编写SELECT语句，该语句考虑了所有3种情况。带有通配符的简单语句似乎失败了，我的头脑在以从右到左的方式“读取”@ANI和cANI值的大小写标准、包含甚至反向策略上转来转去

我的梦想是在两者之间找到最有可能的匹配。我愚蠢的程序如下；非常感谢您的任何帮助！。顺便说一句，我的源表custdatabyni确实包含一个RevANI列，它只是cANI值的倒数。起初我认为解决方案可能在于反转@ANI参数值，并在[RevANI]列中找到最大匹配，从而在每个列的右侧保留任何通配符。但我仍然被困住了，不确定这是否是最好的策略。。。。

如果要加快查询速度，可以创建一个电话号码顺序相反的传统列，在该列上建立索引，然后使用LIKE谓词查询号码，并以相反顺序传递搜索到的电话号码。这将使查询尽可能快。例如，对于示例数据，您可以将其存储在new ReversedPhoneNumber列中：

当您需要通过6543211234进行查询时，只需将其反转，然后像这样查看反转列

WHERE ReversedPhoneNumber LIKE `6543211234%`

这将以存储的任何格式匹配数字，而且非常快，因为这是一个简单而快速的索引查找。一个类似于启动操作的类将寻找索引以寻找巧合

至于您需要应用的其他规则，您比我们更了解这些数据。只需考虑所有可能的情况并进行一些测试，您就可以得到您需要应用的规则，而不是加速，以确保正确匹配

您可以在ETL过程中反转电话号码

缺少一些细节来提供更好的建议

注意：如果不能向现有表中添加列和索引，只需创建一个不同的表来保存与现有表相关的反向编号。您还可以添加触发器来维护此表

是否考虑使用RIGHT@ANI，10=[cANI]？是的……我过去在处理有点坚定的美国专用电话号码时有这个“规则”。但是，我想在全球范围内使用相同的数据集，因为存在更多的可变性。8到15位之间的大容量表示感谢您的建议。我确实有一个索引反向电话号码列

[RevANI]这将很好地配合您的提案。我需要帮助的情况下，当然后声明，特别是与LEN限制。我希望避免将“短”电话号码（可能小于8位）与查找表中的多个13位长的值相匹配……您需要显示更多的用例，以便我们能够提供更多有用的建议。这是定义工作规则的关键。我已经编辑了最初的帖子，以包含这3个案例。我担心像“@ANI%”这样的RevANI可能会在案例2中失败。是的，那会失败，但这只是一个语法问题：像@ANI+'%”这样的RevANI在哪里。当然，您可以选择两种或两种情况。

6543211234     store as: 4321123456
16543211234    store as: 43211234561 
0016543211234  store as: 4321123456100

WHERE ReversedPhoneNumber LIKE `6543211234%`