A HASHBYTES
função ocupa apenas 8000 bytes como entrada. Porque suas entradas são potencialmente maiores do que isso, duplica na faixa do campo que fica hash irá causar colisões, independentemente do algoritmo escolhido. Considere com cuidado o intervalo de dados que planeja fazer hash - o uso dos primeiros 4000 caracteres é a escolha óbvia , mas pode não ser a melhor opção para seus dados.
De qualquer forma, devido ao que é uma função hash, mesmo que as entradas tenham 8000 bytes ou menos, a única maneira de garantir 100% de correção nos resultados é comparar os valores base em algum momento (leia-se: não necessariamente primeiro ). Período.
A empresa determinará se é necessária 100% de precisão. Isso informará que (a) a comparação dos valores base é necessária ou (b) você deve considerar não comparar os valores base - quanta precisão deve ser trocada pelo desempenho.
Embora colisões de hash sejam possíveis em um conjunto de entradas exclusivo, elas são infinitesimalmente raras, independentemente do algoritmo escolhido. A ideia geral de usar um valor de hash nesse cenário é restringir eficientemente os resultados da junção a um conjunto mais gerenciável, para não necessariamente chegar ao conjunto final de resultados imediatamente. Novamente, para 100% de precisão, essa não pode ser a etapa final do processo. Esse cenário não está usando hash para fins de criptografia, portanto, um algoritmo como o MD5 funcionará bem.
Seria extremamente difícil para mim justificar a mudança para um algoritmo SHA-x para fins de "precisão", porque, se a empresa estiver enlouquecendo com as minúsculas possibilidades de colisão do MD5, é provável que ela também esteja enlouquecida. os algoritmos SHA-x também não são perfeitos. Eles precisam aceitar a pequena imprecisão ou exigir que a consulta seja 100% precisa e viva com as implicações técnicas associadas. Suponho que se o CEO dorme melhor à noite sabendo que você usou SHA-x em vez de MD5, tudo bem; ainda não significa muito do ponto de vista técnico neste caso.
Falando em desempenho, se as tabelas forem lidas principalmente e o resultado da junção for necessário com frequência, considere implementar uma exibição indexada para eliminar a necessidade de calcular a junção inteira toda vez que solicitada. É claro que você troca o armazenamento por isso, mas pode valer a pena pela melhoria no desempenho, principalmente se for necessária uma precisão de 100%.
Para uma leitura mais aprofundada sobre a indexação de valores de cadeia longa, publiquei um artigo que mostra um exemplo de como fazer isso para uma única tabela e apresenta coisas a serem consideradas ao tentar o cenário completo nesta pergunta.