이 HASHBYTES기능은 입력으로 최대 8000 바이트 만 사용합니다. 입력이 그보다 클 수 있으므로 해시되는 필드 범위에서 복제 하면 선택한 알고리즘에 관계없이 충돌 이 발생합니다. 해시하려는 데이터의 범위를 신중하게 고려하십시오. 처음 4000자를 사용하는 것이 분명한 선택이지만 최선의 선택 이 아닐 수도 있습니다 .
어쨌든 해시 함수의 특성으로 인해 입력이 8000 바이트 이하인 경우에도 결과의 100 % 정확성을 보장 하는 유일한 방법은 특정 시점에서 기본 값을 비교하는 것입니다 (읽기 : 반드시 첫 번째는 아님). 기간.
비즈니스는 100 % 정확도가 필요한지 여부를 지시합니다. 이 기본 값을 비교하거나 (A)가되는 것을 당신에게 말할 것이다 요구 , 또는 (b) 당신이해야 고려 하지 기본 값 비교 - 성능을 절충해야한다 얼마나 정확성을.
고유 한 입력 세트에서 해시 충돌이 발생할 수 있지만 선택한 알고리즘에 관계없이 무한히 드물게 발생합니다. 이 시나리오에서 해시 값을 사용하는 전체 아이디어는 조인 결과를보다 관리하기 쉬운 집합으로 효율적으로 좁히고 최종 결과 집합에 즉시 도달 할 필요는 없습니다. 다시 말하지만, 100 % 정확성을 위해, 이것은 프로세스의 마지막 단계가 될 수 없습니다 . 이 시나리오는 암호화 목적으로 해싱을 사용하지 않으므로 MD5와 같은 알고리즘이 제대로 작동합니다.
"정확성"목적으로 SHA-x 알고리즘으로 올라가는 것을 정당화하는 것은 극히 어려운 일입니다. 왜냐하면 MD5의 작은 충돌 가능성에 대해 비즈니스가 혼란 스러울 경우, 그 가능성 또한 놀라 울 것입니다. SHA-x 알고리즘도 완벽하지 않습니다. 그들은 약간의 부정확성을 가지고 있거나 쿼리가 100 % 정확해야하며 관련 기술에 영향을 미치도록 요구해야합니다. 나는 CEO가 MD5 대신 SHA-x를 사용했다는 것을 알고 밤에 더 잘 자고 있다고 생각합니다. 이 경우 여전히 기술적 관점에서 그다지 큰 의미는 아닙니다.
성능에 관해 말하면, 테이블이 가장 많이 읽히고 조인 결과가 자주 필요한 경우 인덱스 뷰를 구현하여 요청 될 때마다 전체 조인을 계산할 필요가 없도록하십시오. 물론이를 위해 스토리지를 교환해야하지만 특히 100 % 정확도가 필요한 경우 성능 향상에 가치가있을 수 있습니다.
긴 문자열 값 인덱싱에 대한 자세한 내용 을 보려면 단일 테이블에 대해이 작업을 수행하는 방법에 대한 예제를 안내 하고이 질문의 전체 시나리오를 시도 할 때 고려해야 할 사항을 설명 하는 기사 를 게시했습니다 .