我们希望确保具有两个不同nvarchar值的重复哈希值的风险是最小的.根据我对互联网的研究,MD5似乎是最好的.是对的吗？ MSDN告诉我们(链接如下)关于可用的算法,但没有描述哪个条件适用于哪些条件？
我们需要在两个nvarchar(max)列上连接两个表.您可以想象查询需要花时间执行.我们认为最好保留每个nvarchar(max)数据的哈希值,并对哈希值而不是作为blob的nvarchar(max)值进行连接.问题是哪个哈希算法提供了唯一性,因此我们不会遇到为一个以上的nvarchar(max)设置一个哈希值的风险.
解决方法
HASHBYTES功能最多只需8000字节作为输入.由于输入可能大于此输入,因此无论选择何种算法,在散列字段范围内的重复项都将导致冲突.仔细考虑您计划散列的数据范围 – 使用前4000个字符是显而易见的选择,但可能不是您数据的最佳选择.
无论如何,由于哈希函数是什么,即使输入是8000字节或更少,确保结果100％正确性的唯一方法是在某一点比较基值(读：不一定是第一).期.
该业务将决定是否需要100％的准确性.这将告诉您(a)需要比较基值,或者(b)您应该考虑不比较基值 – 应该为性能换取多少准确度.
虽然在唯一的输入集中可能存在哈希冲突,但无论选择哪种算法,它们都是极少见的.在这种情况下使用哈希值的整个想法是有效地将连接结果缩小到更易于管理的集合,而不是立即到达最终的结果集.同样,对于100％的准确性,这不是该过程的最后一步.此方案不使用散列来进行加密,因此MD5等算法可以正常工作.
我很难证明为了“准确”的目的而采用SHA-x算法是正确的,因为如果企业想要对MD5的微小碰撞可能性感到恐惧,那么他们很可能也会惊慌失措. SHA-x算法也不完美.他们要么必须接受轻微的不准确性,要么要求查询100％准确并且与相关的技术含义相关.我想如果CEO晚上睡得好,知道你使用SHA-x而不是MD5,那么,很好;在这种情况下,从技术角度来看,它仍然没有多大意义.
说到性能,如果表是主要读取的并且经常需要连接结果,请考虑实现索引视图,以消除每次请求时计算整个连接的需要.当然,您需要权衡存储,但是对于性能改进可能是值得的,特别是如果需要100％的准确性.
有关索引长字符串值的进一步阅读,我将介绍如何为单个表执行此操作的示例,并介绍在此问题中尝试完整方案时要考虑的事项.
