Meu DBA e eu estamos tendo um desacordo sobre a estrutura do índice.
Considere dados para uma alegação médica...
Temos a Headertabela com campos como:
ClaimId (varchar(50)), PaidAmount, MemberID...
e para cada cabeçalho temos um ou mais registros Detailcomo:
ClaimId (varchar(50)), LineNumber (smallint), MemberId...
A eficiência da estrutura ou duplicação dos dados está fora dos parâmetros desta questão.
Existem tabelas adicionais que se ligam a Detaillinhas individuais por , e ClaimId, LineNumbernós frequentemente também.JOIN DetailHeaderClaimId
Para a Detailtabela, que seria preferível para a chave de índice clusterizado:
ClaimId
ou
ClaimId, LineNumber
ClaimIdsozinho NÃO é único, mas a combinação de ClaimId, LineNumberé única para um Detailregistro.
Um de nós acredita que ClaimIdsozinha é uma chave agrupada melhor porque é mais estreita e que a pesquisa será igualmente eficiente, pois precisamos saber o ClaimIdantes de pesquisar o LineNumber.
O outro acredita que a combinação dos dois é melhor porque elimina a necessidade de um adicional RowID, e pode ser usado em JOINmesas de suporte que precisam do LineNumbercomo JOINcondição.
Isso é besteira:
devido a esta
Um índice clusterizado não exclusivo adicionará um unificador de 4 bytes para remover a ambigüidade de ClaimId porque é o índice clusterizado . Por quê? Um motivo é que todos os índices NC se referem a ele: então, como saber ClaimId é qual?
Foi demonstrado (algum tempo atrás, talvez não seja válido agora e não consigo encontrá-lo) que os índices clusterizados não exclusivos quebram quando você esgota 2 ^ 32 valores do unificador de 4 bytes
Editar:
A pergunta afirma que ClaimId não é exclusivo, portanto, supõe-se que o uniqifier exista. Não há necessidade de comentar que pode não existir no contexto da pergunta